Resource scheduling in direct device to device communications systems

ABSTRACT

Methods, systems, and apparatuses of a wireless communications network can involve transmitting, to a first user equipment (UE), configuration information for the first UE (UE1 configuration information) for an inter-device session (IDS) between the first UE and a second UE. The UE1 configuration information may include a first IDS radio network temporary identifier (IDS-RNTI). A radio resource control (RRC) message indicating a resource allocation can be transmitted to the first UE for the first UE to communicate directly with the second UE.

FIELD

This disclosure relates to direct device-to-device (DD2D) communicationsin a mobile communications network.

BACKGROUND

Communication networks include wired and wireless networks. Examplewired networks include the Public Switched Telephone Network (PSTN) andEthernet local area networks. Example wireless networks include licensedcellular networks as well as unlicensed wireless networks that connectto wired networks. Calls and other communications may be connectedacross wired and wireless networks.

In wireless cellular networks, mobile devices generally communicate witheach other by transmitting and receiving data traffic through basestations or other similar network nodes, even when the mobile devicesare in close proximity. Direct communications between mobile devices ina licensed band without network control can cause interference to othermobile devices operating in the network.

With the proliferation of devices equipped with a cellular modem, directdevice-to-device communication offers itself as a potential feature thatmay significantly enhance the performance of wireless communicationstechnology.

Furthermore proximity-based applications and services represent a recentand enormous social-technological trend. The introduction of a directcommunication capability would allow the wireless communicationsindustry to promote this important trend. Additionally, there is alsointerest in the ability to offload the network in some cases via directdevice-to-device communication.

DESCRIPTION OF DRAWINGS

FIG. 1 is a schematic block diagram of an example mobile communicationsystem.

FIG. 2 is a schematic illustrating an example network node.

FIG. 3 is a schematic illustrating an example user equipment device.

FIG. 4A is a schematic illustrating an example of signaling and trafficfor an inter-device session (IDS), where a first user equipment UEreceives signaling feedback directly from a second UE.

FIG. 4B is a schematic illustrating an example of signaling and trafficfor an inter-device session (IDS), where a user equipment (UE)communicates signaling feedback to a network node (e.g., an evolved NodeB (eNB)).

FIG. 5A is a message sequence diagram illustrating an example signalflow and traffic for an inter-device session in which a first UEreceives feedback signaling directly from a second UE.

FIG. 5B is a message sequence diagram illustrating an example signalflow and traffic for an inter-device session in which feedback signalingis transmitted to a network node (e.g., an evolved Node B (eNB)).

FIG. 6 is a message sequence diagram illustrating an example networkoperation for an inter-device session.

FIG. 7 is a flow chart illustrating an example process of IDScommunications performed by a network node.

FIG. 8 is a flow chart illustrating an example process of IDScommunications performed by a user equipment.

FIG. 9 is a graphical diagram showing the sub-band allocation of IDSresources for an inter-device session physical uplink control channel.

FIG. 10 is a process flow diagram illustrating an example of resourceallocation.

Like reference symbols in the various drawings indicate like elements.

DETAILED DESCRIPTION

Certain aspects of the present disclosure pertain to systems,apparatuses, and methods performed by a network node of a wirelesscommunications network. Configuration information can be transmitted toa first user equipment (UE) (UE1 configuration information) for aninter-device session (IDS) between the first UE and a second UE, the UE1configuration information including a first IDS radio network temporaryidentifier (IDS-RNTI). A radio resource control (RRC) message indicatinga resource allocation can be transmitted, e.g., to the first UE or thefirst and second UEs, for the first UE to communicate directly with thesecond UE.

In certain implementations, configuration information for the second UE(UE2 configuration information) for an inter-device session (IDS)between the first UE and a second UE can be transmitted to UE2, the UE2configuration information including a second IDS radio network temporaryidentifier (IDS-RNTI). A radio resource control (RRC) message can betransmitted to the second UE indicating a resource allocation for thefirst UE to communicate directly with the second UE.

In certain implementations, the RRC message may be transmitted to thefirst UE and the second UE separately.

In certain implementations, the RRC message may be repeatedlytransmitted to the first UE and the second UE. The first UE and thesecond UE can be instructed to refrain from transmittingacknowledgement/negative acknowledgement (ACK/NACK) messages.

In certain implementations, the resource allocation identifies aresource for hybrid automatic repeat request (HARQ) transmissions. Incertain implementations, the resource allocation identifies a resourcefor the first HARQ transmission, and the method further comprisesidentifying resources for subsequent HARQ retransmissions.

In certain implementations, an indication of an IDS-physical uplinkcontrol channel (IDS-PUCCH) of the first UE may be transmitted to thesecond UE, the IDS-PUCCH identifying a resource on which to transmit anacknowledgment/negative acknowledgement (ACK/NACK) indicator. The firstUE can be instructed to receive the ACK/NACK indicator from the secondUE.

In certain implementations, the first UE and the second UE areconfigured to refrain from transmitting acknowledgement/negativeacknowledgement (ACK/NACK) messages in response to IDS transmissions.The maximum number of transmissions may be configured and known to theUEs

In certain implementations, wherein the transmitting UE may adjust themodulation and coding scheme (MCS) of the UE-to-UE transmission. Thetransmitting UE indicating the MCS change or new MCS via an IDS-MAC CE,where the IDS-MAC CE is sent over direct device-to-device resources.

In certain implementations, the transmitting UE may adjust the IDStransmission power level of the UE-to-UE transmission. The transmittingUE can indicate the IDS transmission power level change or new IDStransmission power level via an IDS-MAC CE, where the IDS-MAC CE is sentover direct device-to-device resources.

In certain implementations, the transmission on the resources allocationis scrambled by one of the IDS-RNTI of the UE-to-UE session, theIDS-SPS, or IDS-PS RNTI, as configured by the RRC resource allocation.

In certain implementations, the resource allocation identifies aresource for the first HARQ transmission. Resources for ACK/NACKtransmission from UE2 can be configured in response to IDStransmissions; and allocating IDS resources for re-transmissionsaccording to the ACK/NACK feedback.

Certain implementations may include transmitting to the first and secondUE the configuration of an IDS receiver control channel (IDS-RxCCH), theIDS-RxCCH configuration identifying a resource on which to transmitfeedback directly from UE2 to UE1.

Certain implementations may include transmitting to the first and secondUE the configuration of an IDS transmitter control channel (IDS-TxCCH),the IDS-TxCCH configuration identifying a resource on which to transmitcontrol information directly from UE1 to UE2. In implementations whereUE1 is the transmitting UE, UE1 may use the IDS-TxCCH indicate a changein the modulation and coding scheme (MCS) of the UE-to-UE transmission.In some implementations, UE1 is the transmitting UE and may use theIDS-TxCCH to indicate a change in the transmission parameters of theUE-to-UE transmission. In implementations when UE2 is the receiving UE,UE2 may use the IDS-RxCCH to instruct UE1, the transmitting UE, toadjust the IDS transmission power level of the UE-to-UE transmission. Inimplementations when UE2 is the receiving UE, UE2 may use the IDS-RxCCHto send IDS CQI information to UE1, the transmitting UE. Inimplementations where UE2 is the receiving UE, UE2 may use the IDS-RxCCHto send ACK/NACK indications to UE1, the transmitting UE. Inimplementations where UE2 is the receiving UE, UE2 may use the IDS-RxCCHto send a request for a transmission opportunity to UE1, thetransmitting UE.

Certain aspects of the disclosure are directed to systems, methods, andapparatuses for providing an inter-device session where the devices cancommunicate directly, and where the network and the network operatormaintain an acceptable level of control over the device-to-devicecommunication. In the present application, the term “directly” is usedto indicate communications between devices and/or communications betweena device and a network element without intervening devices. For example,a first UE can transmit data and feedback signaling directly to a secondUE without having to transmit the data and feedback signaling to anetwork element. In the interest of consistency, certain examples inthis disclosure may be described in relation to Long Term Evolution(LTE) technology. However, similar device-to-device communicationsaspects described in this disclosure may also be applied to otherwireless communications technologies.

In this disclosure, direct device-to-device communications may bereferenced as an inter-device session (IDS). An inter-device session(IDS) may include configuration to allow communication between two ormore UEs. For a given IDS resource allocation, one UE in the session maybe transmitting in an allotted resource, and other UEs in the sessionare expected to be receiving in that allotted resource. It should beunderstood that the IDS resource may be allocated in resources that maypreviously be considered “uplink” or “downlink” resources. A first UEmay transmit over the IDS resource, and one or more other UEs willreceive the transmission over the IDS resource. Therefore, in someimplementations, the IDS resource may be allocated from either “uplink”or “downlink” portions of the resource pool, where the IDS resource isused for inter-device communications.

The term inter-device session is meant to encompass scenarios where twoor more devices transmit and/or receive data directly with one anothervia a radio channel shared by the two or more devices. As such, the terminter-device session may also be referred to as a multi-device session,plural-device session, Direct Device-to-Device(s) (DD2D), LTE Direct, orother representative terms.

In this application, a name with the prefix “IDS” (Inter-Device Session)refers to an entity, resource, or other concept related to the directUE-to-UE(s) (Device-to-Device(s) (or D2D)) connection (e.g., IDS-PUCCH,IDS-PUSCH, IDS-RNTI) while a name without the “IDS” prefix refers to anentity related to standard UE-to-eNB connections (e.g., physical uplinkcontrol channel (PUCCH), physical uplink shared channel (PUSCH),physical downlink shared channel (PDSCH), radio network temporaryidentifier (RNTI), physical downlink control channel (PDCCH)).

In a first example embodiment, an eNB in an LTE system can allocateresources to one user equipment (UE) for direct communication withanother UE. It is possible for the UEs to conduct a UE-to-UE datasession without continuous eNB involvement. In particular, thetransmitting UE may receive the ACK/NACK response sent by the receivingUE(s) in an IDS resource. In this scheme, data traffic and feedbacksignalling may be transmitted directly between the UEs. It should beunderstood that while data and feedback signalling may be transferredfrom one UE to another UE using allocated IDS resources, a network nodeof a wireless communications network may still be utilized to controlcertain aspects of the IDS. For example, a Physical Uplink ControlChannel (PUCCH) and other control channels may be used to transmitcontrol information related to an IDS to the eNB from each UE as needed.Additionally, in some embodiments, the UEs may also listen to the otherUE's PUCCH, Sounding Reference Signals (SRS) or other reference signaltransmissions where the eNB is the primary intended recipient. Further,in some embodiments, control information such as resource allocation,Modulation and Coding Scheme (MCS) for traffic, and power controlcommands related to an IDS may be transmitted to the UE(s) from the eNB;in other embodiments, some of this control information may be exchangeddirectly between UEs.

After session initiation, each of the UEs may be assigned aninter-device session semi-persistent scheduling (IDS-SPS) orinter-device session persistent scheduling (IDS-PS) assignment fortransmission (described in more detail below). Due to this assignment,the reoccurring resources for UE-to-UE transmissions are known to theother UEs, so no further allocations need to be signaled by the eNB. Inone embodiment, the UEs may be given the location and configuration ofthe other UE's IDS-PUCCH. The IDS PUCCH is a PUCCH configuration withACK/NACK, CQI and other feedback related to the IDS configured by theeNB. Knowing the other UE's IDS-PUCCH, the eNB may instruct the UE toread the ACK/NACK response of the other UE to the UE-to-UE packettransmission. By reading this information, further allocations andACK/NACK responses from the eNB are not required, and the UEs maytransfer data autonomously. The behavior of the UE is indicated in Table1.

TABLE 1 UL HARQ Operation for UE-UE IDS-SPS Autonomous Mode HARQfeedback UE behaviour (next IDS-SPS seen by the UE opportunity) ACK Newtransmission NACK Non-adaptive retransmission

In some embodiments, the IDS-PUCCH is configured for a UE to providefeedback related to the IDS channel as described. In further examples inthis document, the examples focus on the IDS-PUCCH format of UE-to-UEfeedback; however, channel structures are possible. In some embodiments,the feedback can be given over an IDS receiver control channel(IDS-RxCCH) that is configured as part of an IDS link that may or maynot have the same physical structure as the PUCCH channel. In some otherembodiments, this signaling is transmitted within resources allocatedfor IDS transmission. In yet some other embodiments, control andfeedback information is exchanged directly between UEs via IDS MACcontrol elements (CEs) transmitted over the allocated IDS resources. Ingeneral, one or more or all of the control channels may be defined foran IDS.

In the previous example of operation, the control information provideddirectly UE-to-UE is ACK/NACK response to IDS transmissions; however,other feedback types are possible for any of the UE-to-UE controlchannel discussed. This feedback could include CQI/CSI, ACK/NACK,scheduling request, transmit power control or other receiver feedbackand control information. In some cases, one or more of these informationelements can be sent in the same message.

Further in the previous example of operation, the location andconfiguration information of the IDS-PUCCH, or the IDS-RxCCH, of one UEcan be given to the other UE for receiving so that direct UE-to-UEfeedback can occur. In some other embodiments, the location andconfiguration of the IDS-PUCCH or IDS-RxCCH may be inherent in thestructure of the IDS channel, obviating the need for an eNB to providethis information explicitly to the UEs.

The terms UE1 and UE2 are used here for simplicity and clarity, and arenot meant to convey a particular order of the process, a particularactor, or limit the number of devices involved.

Each inter-device session is identified by an inter-device session radionetwork identifier (RNI) that is assigned by the network node (e.g.,eNB) of the wireless communications network. One example of a radionetwork identifier used in accordance with this disclosure is a radionetwork temporary identifier assigned to an inter-device session in anLTE system (IDS-RNTI). PDCCH/enhanced physical downlink control channel(ePDCCH) messages related to an IDS may be configured with the IDS-RNTI.Therefore, a UE must attempt to decode PDCCH/ePDCCH messages using theIDS-RNTI(s) assigned to its session(s). This may be done in addition todecoding messages addressed to other RNTIs associated with the UE. Theterm “configured with” can include, among other things, configured by,corresponding to, addressed to, directed to, scrambled with, encodedwith, portion encoded with (e.g., cyclic redundancy check (CRC)scrambled with the radio network identifier (RNI), such that the controlmessage can be determined to be addressed to a UE that knows the RNI),referencing, etc.

IDS resource allocations signalled in the PDCCH/ePDCCH and configuredwith the IDS-RNTI may indicate grants for direct UE-to-UE transmissions.IDS resource allocations may be signalled in control messages sent fromthe eNB to one or more UEs participating in the inter-device session. Inone embodiment, a control message configured with an IDS-RNTI assignedto an individual UE is sent to each of the UEs participating in theinter-device session, such that the UEs are all made aware of the IDSresource allocations being granted for the inter-device session. Inanother embodiment where the IDS-RNTI refers to a session with two ormore UEs, the IDS resource allocation configured with the IDS-RNTI mayalso be configured with a UE session ID associated with one of the UEsin the IDS (for example, the grant of the IDS resource allocation mayinclude the UE session ID of the UE that should transmit using the IDSresource).

In an alternate embodiment, there may be more than one IDS Radio NetworkTemporary Identifier (RNTI) assigned for an inter-device session. Forexample, a first IDS-RNTI is assigned to indicate transmission from afirst UE to a second UE, while a second IDS-RNTI may be assigned toindicate transmissions from the second UE to the first UE. In thisalternate embodiment, each IDS-RNTI may be assigned for a particulartransmission direction, or more specifically, to a particular UE thatmay act as a transmitter in the inter-device session. In this alternateembodiment, the network node (e.g., eNB) may maintain a group contextthat includes a first UE's unique IDS-RNTI, and the other UEs that areconfigured to receive transmission from the first UE; the eNB alsoprovides the other UEs with the first UE's unique IDS-RNTI so that theother UEs can identify resource allocations where they act as areceiver.

Advantages of using the IDS-RNTI as described in this disclosure may benumerous. For example, the network node (e.g., eNB) can use the IDS-RNTIto control allocation for each transmission thereby ensuring that UE-UEcommunications do not interfere with neighbouring UEs. Meanwhile sharingan IDS-RNTI amongst UEs participating in the inter-device session mayreduce control channel overhead since one Physical Downlink ControlChannel (PDCCH) transmission is used to signal allocations for both thetransmitter and receiver(s).

FIG. 1 is a schematic block diagram of an example mobile communicationsystem 100. The mobile communication system 100 shown in FIG. 1 mayinclude one or more network nodes (e.g., 112 a and 112 b). It will beunderstood that the network node may take several forms in a mobilecommunication system, such as (but not limited to) an evolved Node B(eNB), a base station, a Node B, a wireless access point, a radionetwork controller, a base transceiver station, a layer two relay node,a layer three relay node, a femto cell, home evolved Node B (HeNB), ahome Node B (HNB), a base station controller, or other network node thatincludes radio resource control. In the long term evolution (LTE)example of FIG. 1, the network nodes are shown as evolved Node Bs (eNBs)112 a and 112 b. The example mobile communication system 100 of FIG. 1may include one or more radio access networks 110, core networks (CNs)120, and external networks 130. In certain implementations, the radioaccess networks 110 may be evolved-UMTS terrestrial radio accessnetworks (E-UTRAN). In addition, in certain instances, core networks 120may be evolved packet cores (EPCs). Further, there may be one or moremobile electronic devices 102 a, 102 b operating within the mobilecommunication system 100. In some implementations, 2G/3G systems 140,e.g., Global System for Mobile communication (GSM), Interim Standard 95(IS-95), Universal Mobile Telecommunications System (UMTS) and CDMA2000(Code Division Multiple Access) may also be integrated into the mobilecommunication system 100.

In the example LTE system shown in FIG. 1, the radio access network 110includes eNB 112 a and eNB 112 b. Cell 114 a is the service area of eNB112 a, and Cell 114 b is the service area of eNB 112 b. In this example,UEs 102 a and 102 b operate in Cell 114 a and are served by eNB 112 a.The UEs 102 a and 102 b may be any electronic device used by an end-userto communicate, for example, within the mobile communication system 100.The UEs 102 a and 102 b may transmit voice data, video data, user data,application data, multimedia data, text, web content and/or any othercontent.

The UE 102 a or 102 b may be referred to as mobile electronic device,user device, mobile station, subscriber station, portable electronicdevice, mobile communications device, wireless modem, or wirelessterminal. Examples of a UE (e.g., UE 102 a or 102 b) may include acellular phone, personal data assistant (PDA), smart phone, laptop,tablet personal computer (PC), pager, portable computer, portable gamingdevice, wearable electronic device, or other mobile communicationsdevice having components for communicating voice or data via a mobilecommunication network.

Other examples of a UE include, but are not limited to, a television, aremote controller, a set-top box, a computer monitor, a computer(including a tablet, a desktop computer, a handheld or laptop computer,a netbook computer), a microwave, a refrigerator, a stereo system, acassette recorder or player, a DVD player or recorder, a CD player orrecorder, a VCR, an MP3 player, a radio, a camcorder, a camera, adigital camera, a portable memory chip, a washer, a dryer, awasher/dryer, a copier, a facsimile machine, a scanner, amulti-functional peripheral device, a wristwatch, a clock, and a gamedevice, etc. The UE 102 a or 102 b may include a device and a removablememory module, such as a Universal Integrated Circuit Card (UICC) thatincludes a Subscriber Identity Module (SIM) application, a UniversalSubscriber Identity Module (USIM) application, or a Removable UserIdentity Module (R-UIM) application. Alternatively, the UE 102 a or 102b may include the device without such a module. The term “UE” can alsorefer to any hardware or software component that can terminate acommunication session for a user. In addition, the terms “userequipment,” “UE,” “user equipment device,” “user agent,” “UA,” “userdevice,” and “mobile device” can be used synonymously herein.

A radio access network is part of a mobile communication system whichimplements a radio access technology, such as UMTS, CDMA2000 and 3GPPLTE. For example, the radio access network (RAN) 110 included in an LTEtelecommunications system is called an EUTRAN. The EUTRAN can be locatedbetween the UEs and core network 120 (e.g., an evolved packet core,EPC). The EUTRAN includes at least one eNB. The eNB can be a radio basestation that may control all or at least some radio related functions ina fixed part of the system. The at least one eNB can provide radiointerface within their coverage area or a cell for the UEs tocommunicate. The eNBs may be distributed throughout the cellular networkto provide a wide area of coverage. The eNBs directly communicate withone or more UEs, other eNBs, and the core network.

This disclosure describes several ways that an inter-device session maybe initiated. For example, a UE could initiate an inter-device sessionresponsive to a user action, the presence of data at the device intendedfor a potentially nearby device, detection of signals from a proximatedevice, or an in-device application exchanging location information withother devices. Alternatively, the network could create an inter-devicesession at its discretion, based on one or more of the followingfactors: UE location, network traffic, operator policies, usersubscription and UE capabilities.

Once it is determined that attempting an IDS connection between two ormore UEs is appropriate, the eNB sends IDS configuration information tothe UEs to enable the inter-device session. IDS configurationinformation for each UE may include the IDS-RNTI and, optionally, a UEsession ID used to identify the UE within this IDS as well as the SRS/RSand IDS PUCCH channel assigned to the UE. The IDS configurationinformation may also be used to facilitate various aspects such astiming and Channel Quality Indicator (CQI) feedback.

Furthermore, if the UE is transmitting and/or receiving in multipleinter-device sessions, the eNB may configure the UE with multipleIDS-RNTIs. The eNB may maintain an IDS group context for eachinter-device session in the eNB coverage area. The IDS group context mayinclude the IDS-RNTI for each UE in the inter-device session, a UEsession ID (if configured) for the UE, and identifiers of other UEs thatmay be part of the inter-device session.

A transmitting UE may align its IDS-transmit-timing with a transmissionresource subframe as directed by the network node timing. In oneembodiment, the UE may adjust its IDS transmission timing according to atiming advance command from the network node. For example, a first UE(UE1) may be sent a timing advance command from the eNB to adjust UE1'stiming for transmitting IDS transmissions using an IDS. A second UE(UE2) may receive the IDS transmissions according to a timing referencedetected from UE1. For example, UE1 may be configured with SRS or otherreference signal (RS), which UE2 can receive from UE1 to determinereceive window timing for IDS transmissions. In this example, the eNBmust provide UE2 with information on location/configuration of UE1RS/SRS. It should be noted that the RS/SRS configuration may be specificfor the IDS or may be the same RS/SRS configuration used by UE1 forcommunication with the eNB.

As described previously, an IDS resource may use UL radio resources orDL radio resources. For time division duplex (TDD) implementations, theIDS resource allocation may include assignment of particular subframes.For frequency division duplex (FDD) implementations, the IDS resourceallocation may include assignment of particular sub-band frequencies. Inother implementations, the IDS resource allocation may includeassignment of particular component carriers.

For example, in some embodiments, a UE may not be able to transmit andreceive UE-UE (IDS) and UE-eNB transmissions at the same time.Considering an example where UL radio resources are used for the IDSresource allocations, the eNB may allocate the IDS resource such that aUE receives IDS transmissions in an UL subframe that is different fromanother UL subframe that the UE uses for other uplink transmissions tothe eNB. In other words, the eNB may not schedule a UE as the receivingUE in an IDS assignment in a subframe where the UE is scheduled to senda PUCCH, IDS-PUCCH, SRS/RS, or UL-SCH transmission. In addition, the eNBmay assign PUCCH and IDS-PUCCH transmission to occur in different ULsubframes for UEs on the same inter-device session in order to allow forUEs in the session to receive and/or measure the other UEsPUCCH/IDS-PUCCH for the purposes of CQI feedback and/or timing. Just asUL subframes and UL radio resources may be scheduled to avoid overlapwith other UL operations of a UE, there may be implementations where DLradio resources are used for IDS resource allocations, and scheduling iscarefully done to avoid overlap with other DL operations of a UE. Insome FDD embodiments, a UE may be able to receive both IDS-PUSCHtransmissions and PDSCH transmissions in the same subframe on differentcarriers. In other embodiments, a UE may only be able to receive eitheran IDS-PUSCH transmission or a PDSCH transmission, but not both, withina given subframe. The capabilities of the UE are signaled to the eNBduring radio resource control (RRC) connection configuration.

The eNBs 112 a and 112 b may be the end point of the radio protocolstowards the UEs 102 a, 102 b and may relay signals between the radioconnection and the connectivity towards the core network 120. In certainimplementations, the EPC may be the main component of a core network120. The core network 120 may include a backbone network, which may be acentral part of the mobile communication system 100. The core network120 may include other components, such as (but not limited to) amobility management entity (MME), a serving gateway (SGW), and/or apacket data network gateway (PGW). The MME may be the main controlelement in the core network 120 responsible for the functionalitiescomprising the control plane functions related to subscriber and sessionmanagement. The SGW can serve as a local mobility anchor, such that thepackets are routed through this point for intra radio access network 110(e.g., intra-EUTRAN) mobility and mobility with other legacy 2G/3Gsystems 140. The SGW functions may include the user plane tunnelmanagement and switching. The PGW may provide connectivity to theservices domain comprising external networks 130, such as the IPnetworks. The UEs 102 a, 102 b, radio access network 110 (e.g., EUTRAN),and core network 120 (e.g., EPC) are sometimes referred to together asthe evolved packet system (EPS).

Though described in terms of FIG. 1, the present disclosure is notlimited to such an LTE environment.

FIG. 2 is a schematic illustrating an example network node 200. Theexample network node 200 includes a processing module 202, a wiredcommunication subsystem 204, and a wireless communication subsystem 206.The processing module 202 can include one or more processing components(alternatively referred to as “processors” or “central processing units”(CPUs)) operable to execute instructions associated with managinginter-device communications. The processing module 202 can also includeother auxiliary components, such as random access memory (RAM), readonly memory (ROM), secondary storage (for example, a hard disk drive orflash memory). The processing module 202 can execute certaininstructions and commands to provide wireless or wired communication,using the wired communication subsystem 204 or a wireless communicationsubsystem 206. A skilled artisan will readily appreciate that variousother components can also be included in the example network node 200.

The network node may establish an inter-device session by sending IDSconfiguration information (e.g., RRC connection reconfiguration) to eachUE that will be part of the inter-device session. For example, the IDSconfiguration information may be sent in a configuration message (e.g.,an RRC message) to each UE in the inter-device session. It should beunderstood that the IDS configuration information may not be identicalfor each UE in the IDS, but the IDS configuration information sent toeach UE includes the configuration needed for the UE to participate inthe IDS. The IDS configuration information may include an IDS-RNTI usedto configure other IDS-related control messages sent to the UE. Forexample, the network node sends a control message to indicate anallocation of IDS resources (e.g., IDS-PUSCH/PDSCH) for at least thetransmitting UE in the inter-device session using a PDCCH DownlinkControl Information (DCI) configured with the IDS-RNTI. In addition, insome implementations, other control messages may be sent using a PDCCHDCI configured with the IDS-RNTI.

In one embodiment, the network node may manage the power level of theIDS transmissions based on the level of the signal from the transmittingUE received by the receiving UE. The receiving UE may indicate thereceived signal level to the network node, such that the network nodemay send a command to the transmitting UE to adjust the power level forsubsequent IDS transmissions. For purpose of adjusting the power levels,the network node may configure a special transmit power control RNTI forthe IDS for a given UE, including a Transmit Power Control(TPC)-IDS-RNTI (to identify transmit power commands for the IDStransmissions by the UE) in the IDS configuration information. In someembodiments, the power level may be increased until an upper limit isreached. When the power level is beyond a limiting threshold for a UE,the network node may determine that the inter-device session is nolonger appropriate and cause the inter-device session to terminate.

In some embodiments, power control commands may be specific for eitherIDS-PDSCH communications in normally DL radio resources or IDS-PUSCHcommunications in normally UL radio resources for a given UE. In thisembodiment, the network node may configure special transmit powercontrol RNTIs for the IDS for a given UE, including anIDS-TPC-PUSCH-RNTI (to identify transmit power commands for theIDS-PUSCH) and/or IDS-TPC-PDSCH-RNTI (to identify transmit powercommands for the IDS-PDSCH) in the IDS configuration information. Onceconfigured, the network node may use special transmit power controlRNTIs to signal separate commands to adjust power for IDS communicationsfor a UE in UL radio resources separately from those in DL radioresources.

In some further embodiments, the network node may configure specialtransmit power control RNTIs for the IDS for a given UE, including anIDS-TPC-SCH-RNTI (to identify transmit power commands for IDS user datatransmissions) and/or IDS-TPC-CCH-RNTI (to identify transmit powercommands for IDS control data transmissions) in the IDS configurationinformation. Once configured, the network node may use special transmitpower control RNTIs to signal separate commands to adjust power for IDScommunications for a UE separately from the power levels used for UL(UE-eNB) communications.

In some embodiments where the receiving UE determines the receivedsignal level of the IDS transmission from an SRS or other referencesignal from the transmitting UE, the transmitting UE may also beinstructed to adjust the power level for the reference signal insubsequent transmissions.

In some embodiments, the initial transmit power level for IDStransmissions is the same as for UE-to-eNB UL transmissions. In otherembodiments, the initial transmit power level is communicated to a UE bythe eNB during IDS configuration.

Additionally, to gain more accurate timing for the synchronization ofthe receive window, the eNB may provide a UE with information on thelocation and configuration of the other UE's PUCCH and/or SRS (ifavailable) or other reference signal (if available).

FIG. 3 is a schematic illustrating an example UE apparatus. The exampleUE 300 includes a processing unit 302, a computer readable storagemedium 304 (for example, ROM or flash memory), a wireless communicationsubsystem 306, an interface 308, and an I/O interface 310. The wirelesscommunication subsystem 306 may be configured to provide wirelesscommunications for data information or control information provided bythe processing unit 302. The wireless communication subsystem 306 caninclude, for example, one or more antennas, a receiver, a transmitter, alocal oscillator, a mixer, and a digital signal processing (DSP) unit.In some embodiments, the wireless communication subsystem 306 cansupport multiple input multiple output (MIMO) transmissions.

The interface 308 can include, for example, one or more of a screen ortouch screen (for example, a liquid crystal display (LCD), a lightemitting display (LED), an organic light emitting display (OLED), amicroelectromechanical system (MEMS) display), a keyboard or keypad, atrackball, a speaker, and a microphone. The I/O interface 310 caninclude, for example, a universal serial bus (USB) interface. A skilledartisan will readily appreciate that various other components can alsobe included in the example UE device 300. The interface 308 may be ahardware interface that permits/facilitates communication between twodevices.

A UE may indicate to a network node that the UE has data to send toanother UE. For example, the UE may transmit an explicit radio linkprotocol indication requesting an inter-device session with another UE.Alternatively, the UE may simply send data destined to a network addressassociated with the other UE. In the typical embodiment, the networknode will determine whether or not to attempt establishment of aninter-device session. In one embodiment, the network node may configurea reference signal in inter-device session setup commands to atransmitting UE and a receiving UE. The reference signal is transmittedby the transmitting UE and received by the receiving UE to determinewhether the two UEs are in-range to directly communicate. The referencesignal may also be used to determine receive timing window and channelstate information (CSI). A receiving UE may send a feedback message tothe network node to indicate CSI based upon the received referencesignal. Alternatively, the receiving UE may send CSI based upondetection of PUCCH RS or SRS transmissions from the transmitting UE. Inthis alternative, the network node provides the location and/orconfiguration of PUCCH RS or SRS of the transmitting UE to the receivingUE so that the receiving UE can detect these transmissions. In someembodiments, the network node may provide a C-RNTI, IDS-RNTI, or otherRNTI of the transmitting UE to the receiving UE so that the receiving UEis configured to detect the PUCCH transmissions. From feedback aboutchannel state information, the network node may determine to establishthe inter-device session. The feedback may also be used by the networknode to determine appropriate IDS resource allocations.

In some embodiments, the transmitting UE may send an IDS transmissionwith the same subframe timing as other UL transmissions intended for theeNB. In some embodiments, the UEs in an inter-device session may becloser to each other than they are to the eNB. In some of these cases,the receiving UE may initially use its UL transmission timing toestimate the receiving window timing of UE-to-UE transmissions. Fineradjustments to the receive window may be made from reception of one ormore of IDS-PUSCH transmissions, PUCCH transmissions, IDS-PUCCHtransmissions (if available), and SRS transmissions or other referencesignals (if available) from the transmitting UE.

In implementations where IDS resources are allocated from DL radioresources, the UEs may send their IDS transmissions at a time offsetrelative to UL timing as specified by the eNB. In some embodiments, thereceiving UE may require a signal from the transmitting UE in order toestimate appropriate timing of the receive window for IDS transmissionsprior to the initial reception of IDS-PDSCH transmission. In this case,the receiving UE may use one or more of the SRS or other referencesignals or PUCCH or IDS-PUCCH from the transmitting UE.

FIG. 4A is a schematic illustrating an example of signaling and trafficfor an inter-device session (IDS), where a first user equipment UEreceives signaling feedback directly from a second UE. In FIG. 4A, datatraffic 422 a and 422 b may be transmitted directly between the UEs; thecontrol elements PDCCH (412 a and 412 b) are transmitted to the UEs fromthe eNB 402 while IDS related ACK/NACK (420 a and 420 b) and SRS/RS (418a and 418 b) are transmitted to one UE from the other UE. The eNB 402may transmit an IDS-PUCCH 416 a of UE1 404 a to UE2 404 b. In oneembodiment, the UEs may be given the location and configuration of theother UE's IDS-PUCCH 416 a and 416 b, and instructed by the eNB 402 toread the ACK/NACK response of the other UE to the UE-to-UE packettransmission. The UEs use this information to transfer data directly toone another without further allocations and ACK/NACK responses from theeNB 402. This allows the UEs to transfer data autonomously to oneanother. The control elements are described below:

PDCCH (412 a and 412 b): Physical Downlink Control CHannel. A downlinkcontrol channel used to support efficient data transmission in LTE. APDCCH carries a message known as Downlink Control Information (DCI),which may include IDS transmission resource assignments and othercontrol information for a specific UE within an inter-device session orfor all UEs within a session. During the inter-device session, a PDCCHmessage configured via IDS-RNTI may be used to allocate IDS resources toa UE within the session designated as the transmitter within thatsubframe. The subsequent IDS transmissions may occur over regularPUSCH/PDSCH resources designated by the DCI. HARQ operation, powercontrol and timing adjustments may be included in the DCI by the eNB 402for the inter-device session. Further, certain transmission multiplexingand session procedures may be used to properly schedule varioustransmission reception windows for the UEs, as well as minimization ofassigned resources during inactivity. In certain implementations, for anIDS allocation, one control message (e.g., a DCI in the PDCCH) may besent from the eNB that is received and decoded by both transmitting andreceiving UEs.

PUCCH (414 a and 414 b): Physical Uplink Control CHannel. The LTE uplinkphysical channel carrying uplink control information including ChannelQuality Indicators (CQI), Hybrid Automatic Repeat reQuest (HARQ)ACKnowledgment/Negative ACKnowledgment (ACK/NACK) and uplink schedulingrequests. In some embodiments, in addition to its normal PUCCH, a UE isconfigured with an IDS-PUCCH for each inter-device session in which theUE participates.

As described in more detail below, the UE2 404 b may send feedbackrelated to the IDS channel and IDS transmissions directly to UE1configured as part of an IDS link. This feedback could include CQI/CSI,ACK/NACK, scheduling request, transmit power control or other receiverfeedback and control information. In some cases, one or more of theseinformation elements can be sent in the same message such as an asIDS-PUCCH. In other cases, the IDS-PUCCH resources (e.g., IDS-PUCCH 416a and 416 b) for feedback may be derived from related parameters of theIDS transmission and/or assignment for the purpose of at least NACK/ACK.In some of these implementations, UE1 404 a is configured to receive atleast the ACK/NACK feedback from UE2 404 b, while the eNB 402 may alsoreceive some or all of the feedback from UE2 404 b. The feedback to theeNB 402 and UE1 404 a may be separate messages, or the same messagereceived by both. In some case, the eNB 402 may ignore the ACK/NACKinformation as UE1 404 a is making the decision on the HARQ processbased on the ACK/NACK information it receives.

In some embodiments, the UE2 404 b may send feedback related to the IDSchannel and IDS transmissions directly to UE1 404 a over an IDS controlchannel (IDS-RxCCH) 426 a that is configured as part of an IDS link (andvice versa, with UE1 404 a sending feedback to UE2 404 b on IDS-RxCCH426 b, in some implementations). This feedback could include CQI/CSI,ACK/NACK, scheduling request, transmit power control or other receiverfeedback and control information. In some cases, one or more of theseinformation elements can be sent in the same message. In some cases, theIDS-RxCCH may be defined instead of, or in addition to, the IDS-PUCCH.In other cases, the IDS-RxCCH resources for feedback may be derived fromrelated parameters of the IDS transmission and/or assignment for thepurpose of at least NACK/ACK. In some of these implementations, UE1 404a is configured to receive at least the ACK/NACK feedback from UE2 404 bover the IDS-RxCCH, while the eNB 402 may also receive some or all ofthe feedback from UE2 404 b over the IDS-PUCCH. The feedback to the eNB402 and UE1 404 a may be separate messages, or the same message receivedby both. In some cases, the eNB 402 may ignore the information itreceives on the IDS-RxCCH as UE1 404 a is making decisions based on theIDS-RxCCH information it receives.

In still other embodiments, control and feedback information isexchanged directly between UEs via IDS MAC control elements (CEs)transmitted over the allocated IDS resources.

In addition to the IDS-RxCCH, an IDS transmit control channel(IDS-TxCCH) 424 a (from UE1 404 a to UE2 404 b) and 424 b (from UE2 404b to UE1 404 a) may be included. The IDS-TxCCH may include transmissionparameter modification associated with the transmission on the IDS. Forexample, the IDS-TxCCH may include but is not limited to modulation andcoding scheme (MCS), transmit power change, precoder matrix or othermultiple input multi output (MIMO) transmission configuration, packet IDor cyclic packet (as described later), and/or new packet indicator.Generally, a transmitting may be configured with an IDS-TxCCH and areceiver UE with an IDS-RxCCH; however, configurations of none, one orboth are possible. In general, resources for IDS-RxCCH and IDS-TxCCH maydefined within an IDS control channel IDS-CCH. Both UEs in the sessionare aware of the location and configuration of the IDS-CCH throughimplicit configuration through specific or defined IDS resources, orthrough indication by the eNB 402. The IDS-CCH may include IDS-RxCCHcomponents or IDS-TxCCH components depending on the receiving andtransmitting roles of each UE, and the configuration of the IDS.

As an example, an IDS-RxCCH may be configured in resources for feedbackfrom UE2 to UE1, with respect to IDS transmission from UE1 to UE2. Insome embodiments, the resources may be within the IDS resourcesallocation, or may be another periodically re-occurring allocation. In aparticular embodiment, the IDS-RxCCH allocations are configured to occurin the interval between IDS transmission between UE1 and UE2. This is areasonable configuration as it is useful to receive ACk/NACK feedbackafter a packet transmission, in order to determine that a retransmissionis needed prior to the next IDS transmission opportunity. In this case,resources may be allocated via RRC message to UE1 and UE2, and UE2 mayprovide ACK/NACK, CQI and/or other information directly over theseresources. In some embodiments, the time-frequency resources allocatedfor the IDS-RxCCH from UE2 to UE1 do not include IDS-RxCCH transmissionfor other inter-device sessions or other transmission (e.g., theIDS-RxCCH is not code multiplexed with other IDS-RxCCH or othertransmissions). In another embodiment, the IDS-RxCCH may be configuredas part of data traffic IDS resources for transmission from UE2 to UE1,in some cases as a header to the data transmission.

As an example, an IDS-TxCCH may be configured for transmission parameterindication from UE1 to UE2, with respect to IDS transmission from UE1 toUE2. In some embodiments, the resources may be within the IDS resourcesallocation, or may be another periodically re-occurring allocation. In aparticular embodiment, the IDS-TxCCH allocations are configured to occurin the interval between IDS transmission between UE1 and UE2. In thiscase, resources may be allocated via RRC message to UE1 and UE2, and UE2may provide MCS, power level indication, new packet indication, and/orother information directly over these resources. The transmissionparameter indication may apply for the next IDS transmission and furtherIDS transmission until a further change or indication is given. In someembodiments, the time-frequency resources allocated for the IDS-TxCCHfrom UE2 to UE1 do not include IDS-TxCCH transmission for otherinter-device sessions or other transmission (e.g., the IDS-TxCCH is notcode multiplexed with other IDS-TxCCH or other transmissions). Inanother embodiment, the IDS-TxCCH may be configured as part of datatraffic IDS recourses for transmission from UE2 to UE1, in some cases asa header to the data transmission. In this case, the indicationcontained in the IDS-TxCCH may apply to data transmission to which it isa header.

As described above, the IDS-RxCCH is for feedback from UE2 to UE1regarding transmissions from UE1 to UE2, and the IDS-TxCCH is fortransmission parameters from UE2 to UE1 regarding transmissions from UE2to UE1. In some embodiments where two-way communication may be usefulbetween two UEs, and in any of the described IDS-TxCCH exampleconfigurations, the IDS-TxCCH may be co-located in an IDS-CCH with anIDS-RxCCH originating from the same UE. For example, UE2 may beconfigured with an IDS-RxCCH and an IDS-TxCCH. In some embodiments wheretwo-way communication may be useful between two UEs, and in any of thedescribed IDS-TxCCH example configurations, the IDS-TxCCH may beco-located in an IDS-CCH with an IDS-RxCCH originating from the same UE.For example, a set of resources may be assigned for UE2 to send feedbackinformation (IDS-RxCCH) to UE1 which may include ACK?NACK informationregarding a previously received IDS transmission from UE1. Inadditional, in the same set of resources UE2 may also send to UE1transmission parameters (in IDS-TxCCH) regarding a transmission to UE1on IDS resources. In some other embodiments, the resources allocated forIDS-RxCCH and IDS-TxCCH are not related and are allocated separately.For example, in some cases the IDS-TxCCH may be included at thebeginning of resources assigned for IDS transmissions so that theIDS-TxCCH transmission parameters apply to the transmission contained inthe accompanying transmission. In these cases, if the IDS-RxCCH isconfigured, it may be configured in separate resources that do notinclude UE-UE data transmissions.

FIG. 4B is a schematic illustrating an example of signaling and trafficfor an inter-device session (IDS), where user equipment (UE) communicatesignaling feedback to a network node (e.g., an evolved Node B (eNB)402). FIG. 4B includes similar features and reference numbering as inFIG. 4A. In FIG. 4B, data traffic 422 a and 422 b may be transmitteddirectly between the UEs; the control elements PDCCH (412 a and 412 b)are transmitted to the UEs from the eNB while IDS-PUCCH (416 a and 416b) and IDS-related ACK/NACK (420 a and 420 b) and SRS (454 a and 454 b)are transmitted to the eNB 402 from each UE and may, in someembodiments, be received by the other UE (418 a and 418 b). Thesecontrol elements are described below:

PDCCH (412 a and 412 b): Physical Downlink Control CHannel. A downlinkcontrol channel used to support efficient data transmission in LTE. APDCCH carries a message known as Downlink Control Information (DCI),which may include IDS transmission resource assignments and othercontrol information for a specific UE within an inter-device session orfor all UEs within a session. During the inter-device session, a PDCCHmessage configured via IDS-RNTI may be used to allocate IDS resources toa UE within the session designated as the transmitter within thatsubframe. The subsequent IDS transmissions may occur over regularPUSCH/PDSCH resources designated by the DCI. HARQ operation, powercontrol and timing adjustments may be included in the DCI by the eNB forthe inter-device session. Further, certain transmission multiplexing andsession procedures may be used to properly schedule various transmissionreception windows for the UEs, as well as minimization of assignedresources during inactivity. In certain implementations, for an IDSallocation, one control message (e.g., a DCI in the PDCCH) may be sentfrom the eNB 402 that is received and decoded by both transmitting andreceiving UEs. In some cases, the HARQ ACK/NACK information regarding anIDS transmission can be fed back to the eNB 402 by the receiving IDS UEand indicated to the transmitting IDS UE on a physical HARQ indicatorchannel (PHICH) (452 a and 452 b) from the eNB that is decoded by thetransmitting IDS UE.

PUCCH (414 a and 414 b): Physical Uplink Control CHannel. The LTE uplinkphysical channel carrying uplink control information including ChannelQuality Indicators (CQI), Hybrid Automatic Retransmission reQuest (HARQ)ACKnowledgment/Negative ACKnowledgment (ACK/NACK) and uplink schedulingrequests related to communications between the eNB 402 and the UE. Insome embodiments, in addition to its normal PUCCH, a UE is configuredwith an IDS-PUCCH (416 a and 416 b) for each inter-device session inwhich the UE participates in order to communicate IDS-related controland feedback information to the eNB. In some embodiments, as shown inFIG. 4A, a UE may also be configured with a control channel, IDS-CCH(e.g., IDS-TxCCH 424 a and 424 b and IDS-RxCCH 426 a and 426 b),allowing control and feedback information to be transmitted directlybetween UEs. The IDS-CCH may include IDS-RxCCH components or IDS-TxCCHcomponents depending on the receiving and transmitting roles of each UE,and the configuration of the IDS. In other embodiments, IDS-relatedcontrol and feedback information may be exchanged directly between UEsvia IDS MAC control elements (CEs) that are transmitted along with datatraffic (422 a and 422 b) over the allocated IDS resources.

In both FIGS. 4A and 4B, an RRC message 410 a is transmitted from theeNB 402 to UE1 404 a. The RRC message 410 a can configure an IDS-SPS orIDS-PS resource allocation. An IDS-SPS allocation is one that isspecified by the RRC message, and is then activated by a further messagesuch as an specifically configured PDCCH DCI. An IDS-PS allocation isone that is completely specified by the RRC message and requires nofurther activation. The RRC message 410 a may provide configurationinformation for one or more of: data traffic (422 a and 422 b), RS (418a and 418 b) and IDS-CCH (IDS-TxCCH: 424 a and 424 b and IDS-RxCCH: 426a and 426 b). The IDS-SPS resource allocation can be activated by aPDCCH DCI. Similarly, an RRC message 410 b can be transmitted to UE2 404b that includes an IDS-SPS/IDS-PS resource allocation.

FIG. 5A is a message sequence diagram 500 illustrating example signalflow and traffic for an inter-device session. A first UE, referred to asUE1, may indicate to a network node that UE1 has data to send to asecond UE, referred to as UE2 (502). This indication can be a radio linkprotocol indication or a scheduling request; however, it is the networkthat can choose whether or not to attempt a UE-to-UE session. Theindication can also be a data packet destined for the network addressassigned to UE2. It is understood that UE1 may want to send data to asingle UE, UE2, or may want to send data to multiple UEs, such as in amulticast or broadcast session. Generally, the indication sent by UE1and received by the network node indicates that UE1 wants to send datato at least UE2, and possibly other UEs. Other indications are alsocontemplated. For example, UE1 may not have a preference as to whetherUE1 communicates in an inter-device session, or UE1 may specificallyrequest an inter-device session. The network node may decide, based onnetwork conditions, location of the UEs, operator policies, etc.,whether or not the inter-device session is possible. If the network nodedetermines that an inter-device session is possible, the eNB then sendsinformation to start the session to each UE (504). For example, the eNBmay send IDS-configuration information to the UEs. SuchIDS-configuration information can include the reference signals to betransmitted and received to determine the proximity of the UEs and aradio network identifier for the IDS, which may be referred to as an IDSradio network temporary identifier (IDS-RNTI).

This disclosure describes multiple ways that an IDS-RNTI may be used inan inter-device session. A first example embodiment described hereinincludes an IDS-RNTI that may be referred to as a “session IDS-RNTI.” Asession IDS-RNTI is used when the same IDS-RNTI is shared by all UEsparticipating in the inter-device session. All UEs in the inter-devicesession may be able to detect and decode the same control messagestransmitted in the PDCCH from the eNB. If the eNB uses a sessionIDS-RNTI, the eNB may also configure each UE in the IDS with a sessionUE-identifier (UE-ID) unique to each UE within the inter-device session.The UE-ID allows the eNB to identify each UE within the session andallows the UEs to identify each other as part of the inter-devicesession communications. In such a scenario, the control message may alsoinclude the UE-ID to indicate a particular UE associated with thecontrol message. For example, if a UE receives a control messageconfigured with the IDS-RNTI, the UE can check for the UE-ID todetermine if the instruction indicates the UE's UE-ID or if theinstruction indicates another UE's UE-ID.

A second example embodiment described herein includes IDS-RNTIs that maybe referred to as “unidirectional IDS-RNTI” for each UE. For theunidirectional case, additional configuration information may betransmitted to the UEs. A unidirectional IDS-RNTI is used to indicatecommands, messages, and/or feedback that are related to transmissions inone direction—from a first UE to a second UE, but not vice versa.Typically, but not necessarily, there will be two or more unidirectionalIDS-RNTIs assigned for an inter-device session. For example, a firstIDS-RNTI may be assigned to indicate transmissions from UE1, while asecond IDS-RNTI may be assigned to indicate transmissions from UE2. TheeNB may send control messages in the PDCCH configured with theunidirectional first IDS-RNTI to indicate transmission from UE1. All UEsin the inter-device session may be able to detect and decode the samecontrol messages transmitted in the PDCCH from the eNB. The eNB may sendother control messages in the PDCCH configured with the unidirectionalsecond IDS-RNTI to indicate transmission from UE2. Note that theunidirectional IDS-RNTI for a transmitting UE may also be indicated toreceiving UEs during configuration of the inter-device session. In someembodiments using the unidirectional IDS-RNTIs, a UE may be configuredwith two or more IDS-RNTIs (one or more that are specific for the IDStransmissions sent by the UE and other IDS-RNTIs used by othertransmitting UEs from which IDS transmissions may be received).

The eNB communicates the IDS-RNTI (either session IDS-RNTI orunidirectional IDS-RNTIs) as IDS configuration information to a UE. TheIDS configuration information may also include a dedicated supplementalPUCCH allocation (IDS-PUCCH) for IDS feedback or other IDS uplinkrequests to eNB. It should be understood that the IDS-PUCCH may be inaddition to a PUCCH for conventional UE-eNB operations. In someembodiments, the IDS configuration may also include a dedicated controlchannel allocation (IDS-CCH) for communicating IDS control and feedbackinformation directly between UEs. It should be understood that theIDS-CCH allocation may be in addition to the PUCCH and IDS-PUCCHallocations. In the embodiment with a session IDS-RNTI, the IDSconfiguration information may also include the UE-ID for a particular UEin the inter-device session.

In some embodiments, additional IDS configuration information may besent, including a dedicated RNTI (TPC-IDS-RNTI) for power controlcommands sent by the eNB to a particular UE to control power of IDStransmissions. The IDS configuration may include periodic SRSconfiguration or other reference signal (RS) configurations specific tothe IDS. IDS configuration information may also indicate an initialtransmit power level for the IDS transmissions. Additionally, in someinstances, the eNB will indicate how the UEs are to measure the signalstrength from the other UE. In such cases, the eNB may include the otherUE's session ID (within the existing UE-to-UE session), and RS locationand configuration.

In some embodiments, on receiving configuration information from theeNB, one or more of the UEs involved in the session setup may transmit areference signal (IDS-RS) or sounding reference signal (IDS-SRS) asdirected by the eNB session setup commands. One or both of the UEs senda sounding reference signal (IDS-SRS) as indicated by the eNB sessionsetup commands (506). The IDS-SRS is used by the other UE to determinewhether they are in-range to communicate and, if they are, to determinereceive timing window and channel state information (CSI). In someembodiments, the IDS-SRS is the same reference signal (SRS) used forsounding between the UE and the eNB; in other embodiments, the IDS-SRSis distinct from the SRS. In some implementations, one or both of theUEs send an IDS-PUCCH message to the eNB indicating CSI of the receivedIDS-SRS or PUCCH RS from the other UE (508). From this feedback, the eNBdetermines whether it is feasible to start UE-to-UE resourceallocations.

The eNB sends an IDS-SPS-/IDS-PS-Config IE allocation for directresources (510). The eNB sends an IDS-SPS-/IDS-PS-Config IE allocationfor direct UE-to-UE communications. This IE may be unicast to each UE ofthe IDS or, in some embodiments, multicast to the UEs. In the case ofthe IDS-SPS allocation, the eNB activates the allocation for directUL/DL UE-UE resources (IDS-PUSCH/PDSCH) using a PDCCH DCI configuredwith the inter-device session (IDS)-RNTI. Both (or all) UEs decode thismessage, which includes information on which UE is transmitting (UE1 inthis example). In some embodiments, semi-persistent scheduling (SPS)assignment may be given to a direct UE-to-UE traffic channel. In thesecases, the UEs may be configured by radio resource configuration (RRC)signalling to decode Downlink Control Information (DCI) configured by anIDS-SPS-RNTI related to the IDS-SPS assignment. The RRC informationelement, SPS-config, is sent by the eNB to all UEs of the UE-to-UEsession; the information element may be included in an RRC message sentindividually to each UE (i.e., using a PDSCH allocation configured withthe C-RNTI assigned to the UE) or may be included in an RRC messagemulticast to all UEs in the IDS session (i.e., using a PDSCH allocationconfigured with the IDS-RNTI assigned to the session). The IDS-SPSassignment is activated by a transmission of a DCI configured by the SPSIDS-RNTI.

As a general example, the procedure to allocate the SPS by sending RRCsignalling to each UE may include configuring two or more UEs with “IDSsession setup messages,” which may include or be included in an RRCmessage. Within the RRC message sent to each UE, the UEs are given acommon IDS-RNTI to use for UE-to-UE communications within the session.If an IDS-SPS-Config information element is also included in the RRCmessage sent to each UE, then the SPS C-RNTI included in the informationelement is interpreted as an SPS-IDS-RNTI assigned to this IDS. At sometime later, the eNB may send a DCI on a DL control channel (e.g., on thePDCCH/ePDCCH) configured by the SPS-IDS-RNTI of the session to indicatethe start of an SPS allocation for the IDS and the UE session ID of thetransmitting UE for this allocation.

In another general example, the procedure to allocate the SPS bymulti-casting RRC signalling to each UE may include configuring two ormore UEs with “IDS session setup messages,” such as the RRC message.Within the RRC message sent to each UE, the UEs are given a commonIDS-RNTI to use for UE-to-UE communications within the session. Sometimelater, the IE SPS-Config is sent in an RRC message that is multicast toall of the IDS UEs. The RRC message is contained in a PDSCH assignmentusing a Format 1 DCI addressed to the IDS-RNTI of the session, so allUEs of the IDS will attempt to receive it. The SPS C-RNTI included inthe information element is interpreted as an SPS-IDS-RNTI assigned tothis IDS. As the RRC message is multi-cast, and because HARQ ACK/NAK isnot implemented in LTE for multi-cast messages, one of the followingmechanisms may be implemented: (i) the eNB may send the RRC message Ntimes, and the UEs are configured to not send ACK/NAK responses toallocations addressed to IDS-RNTIs, or (ii) the UEs are configured onlyto send NAK if required, and the eNB retransmits the RRC message only ifthe eNB detects a NAK transmitted by at least one UE. At some timelater, the eNB sends a DCI on a DL control channel (e.g., on thePDCCH/ePDCCH). The DCI is configured by the SPS-IDS-RNTI of the session.The DCI also indicates the UE session ID of the transmitting UE for thisallocation.

In both instances, the UE identified by the UE session ID in the DCI isthe designated transmitter in all of the subsequent transmissionopportunities defined by the semi-persistent schedule until and unlessanother DCI addressed to the SPS-IDS-RNTI is included in the PDCCH.

In general for IDS-SPS operation, if the UE has been assigned a UEsession ID within the IDS, then the DCI transmitted on a DL controlchannel may include the UE session ID to indicate the transmitter UE forthe allocation. It may be noted that as the DCI contains the indicationof transmitting UE, in some embodiments the transmitting UE may bechanged via an additional DCI transmission for the same IDS-SPSallocation. Alternatively, the UE session ID may be included in eachIDS-SPS RRC configuration sent to each UE of the IDS (unicast ormulticast) to indicate the transmitting UE for the allocation when theUE session ID is activated.

Otherwise for IDS-SPS operation, if the UE has been not been assigned aUE session ID within the IDS (for example, an IDS-RNTI is assigned thatis “unidirectional” such that the transmitter is implied), the IDS-RNTImay be included in each IDS-SPS RRC configuration sent to each UE of theIDS (unicast or multicast) to indicate the transmitting UE for theallocation when the IDS-RNTI is activated. In other embodiments, theunidirectional IDS-RNTI of the designated transmitter, rather than theUE session ID, is included in the DCI configured with the SPS-IDS-RNTI.Alternatively, the IDS may be configured such that the unidirectionalIDS-RNTI and SPS-IDS-RNTI are the same so that further control messagesrelate to the IDS and the IDS-SPS allocation.

For operation in UL radio resources, SPS operation can be configured bythe SPS-Config IE. In some embodiments, a new UL SPS-Config forinter-device sessions can be defined as the IDS-SPS-ConFIG. In some ofthese embodiments, the IDS-SPS can be defined to be used for the firstHARQ transmissions of a packet only, such that the re-transmissions areexplicitly scheduled. In some other embodiments, the SPS forinter-device session is defined for first HARQ transmissions andretransmissions. This configuration may be defined in specifications orindicated in the IDS-SPS-conFIG. For example, the IDS-SPS-config mayhave an explicit field that indicates whether or not the allocation canbe used for re-transmissions. In another example, a specific value ofone of the fields may indicate this configuration, such as setting thevalue of the implicit release timer to zero.

For operation in DL radio resources, there may be, for example, threeembodiments. First, the SPS-Config for the UL may be re-used as theIDS-SPS-Config; however, the SPS-Config is modified to indicateallocation in the DL radio resources. In a second embodiment, theSPS-Config for the DL is re-used as the IDS-SPS-Config; however, in thisembodiment, resources for retransmission in the DL need to be allocatedseparately as the DL SPS in LTE supports allocations for a first HARQtransmission only. This configuration may be defined in specificationsor indicated in the IDS-SPS-config.

Finally, a modified SPS-Config IE is used as the IDS-SPS-Config for theDL that includes a toggle to allow retransmissions and implicit releasetimer fields. In the example of the modified SPS-Config as shown below,the toggle for allowing retransmission within the DL SPS is embedded inthe implicit release timer.

Modified SPS-Config information element for IDS-SPS-Config -- ASN1STARTIDS-SPS-Config ::= SEQUENCE { IDS-semiPersistSchedC-RNTI C-RNTIOPTIONAL, -- Need OR IDS-sps-ConfigDL SPS-ConfigDL OPTIONAL, -- Need ONIDS-sps-ConfigUL SPS-ConfigUL OPTIONAL -- Need ON } IDS-SPS-ConfigDL ::=CHOICE{ release NULL, setup SEQUENCE { semiPersistSchedIntervalDLENUMERATED { sf10, sf20, sf32, sf40, sf64, sf80, sf128, sf160, sf320,sf640, spare6, spare5, spare4, spare3, spare2, spare1},numberOfConfSPS-Processes INTEGER (1..8), implicitReleaseAfterENUMERATED {e0, e2, e3, e4, e8, spare1, spare2, spare3},n1PUCCH-AN-PersistentList N1PUCCH-AN-PersistentList, ..., [[twoAntennaPortActivated-r10 CHOICE { release NULL, setup SEQUENCE {n1PUCCH-AN-PersistentListP1-r10 N1PUCCH-AN-PersistentList } } OPTIONAL-- Need ON ]] } } IDS-SPS-ConfigUL ::= CHOICE { release NULL, setupSEQUENCE { semiPersistSchedIntervalUL ENUMERATED { sf10, sf20, sf32,sf40, sf64, sf80, sf128, sf160, sf320, sf640, spare6, spare5, spare4,spare3, spare2, spare1}, implicitReleaseAfter ENUMERATED {e2, e3, e4,e8}, p0-Persistent SEQUENCE { p0-NominalPUSCH-Persistent INTEGER(−126..24), p0-UE-PUSCH-Persistent INTEGER (−8..7) } OPTIONAL, -- NeedOP twoIntervalsConfig ENUMERATED {true} OPTIONAL, -- Cond TDD ... } }N1PUCCH-AN-PersistentList ::= SEQUENCE (SIZE (1..4)) OF INTEGER(0..2047) -- ASN1STOP

Modified SPS-Config field descriptions (additonal to SPS-Config)implicitReleaseAfter Number of empty transmissions before implicitrelease. Value e2 corresponds to 2 transmissions, e3 corresponds to 3transmissions and so on. Value of e0 corrsponds to no implicit releaseand the first HARQ transmisisons only (DL SPS only).

In the example of inter-device semi-persistent assignments IE(IDS-SPS-Config) illustrated, both the DL and UL semi-persistentassignments are indicated. In some embodiments, only one of these may bedefined. For example, in a particular embodiment, the IDS-SPS-configULcan be used for semi-persistent assignment in either PUSCH or PDSCHradio resource regions.

In some embodiments, the ACK/NACK operation for IDS-SPS assignments maybe sent to the eNB as described. In these embodiments, it may bedesirable to configure the IDS-SPS resource for first HARQ transmissionsof a packet only and explicitly allocate (via the PDCCH/ePDCCH DCI) theretransmissions.

In some other embodiments, IDS-SPS assignment may be configured suchthat the ACK/NACK responses are received directly by the transmitting UEover the IDS-RxCCH or in MAC CEs so that HARQ transmissions andretransmission may be sent in the IDS-SPS resources without eNBallocations or ACK/NACK indications by the eNB to the D2D transmissions.

In still further embodiments, the system may operate without HARQ, andtransmissions are repeated until a maximum number is reached. In somecases, the maximum number may be specified in the RRC configurationmessages sent to the UEs, while in other cases it may be defined in thespecifications.

In some embodiments where a transmitting UE may adjust the MCS of theIDS transmission, the transmitting UE may indicate the MCS change or newMCS via the IDS-TxCCH or via an IDS-MAC CE, where the IDS-MAC CE is sentover IDS resources.

In addition to the semi-persistent allocation described above, theinter-device session may also operate using persistent allocation. Inpersistent allocation embodiment, the allocation is made by RRCsignalling only and does not require activation via a DCI. In someembodiments, the RRC signalling for persistent scheduling of IDSresources needs to include additional parameters of the transmissionformat, as well as an indication of the UE that will be transmitting. Inother embodiments, this information is exchanged directly between UEsvia the IDS-CCH or via IDS MAC CEs. As in the description of the SPSassignment, the signalling of IDS-PS-Config may be sent to each UEseparately, or multi-cast to UEs of the session using the IDS-RNTI.

In general for IDS-PS operation, if the UE has been assigned a UEsession ID within the IDS, the UE session ID may be included in eachIDS-PS RRC configuration sent to each UE of the IDS (unicast ormulticast) to indicate the transmitting UE for the allocation. Otherwisefor IDS-PS operation, if the UE has been not been assigned a UE sessionID within the IDS (for example, an IDS-RNTI is assigned that is“unidirectional” such that the transmitter is implied), the IDS-RNTI maybe included in each IDS-PS RRC configuration sent to each UE of the IDS(unicast or multicast) to indicate the transmitting UE for theallocation. In other embodiments, the role of transmitting UE isdetermined via signalling over the IDS-CCH or via the exchange of IDSMAC control elements (CEs) over the allocated IDS resources. An exampleof an inter-device persistent assignment IE (IDS-PS-Config) isillustrated below for both the DL and UL persistent assignments. In someembodiments, only one of these may be defined. For example, in aspecific embodiment, the IDS-PS-configUL can be used for persistentassignment in either PUSCH or PDSCH radio resource regions.

IDS-PS-Config information element -- ASN1START IDS-PS-Config ::=SEQUENCE { IDS-PersistSchedC-RNTI C-RNTI OPTIONAL, -- Need ORIDS-PS-ConfigDL IDS-ConfigUL OPTIONAL -- Need ON IDS-PS-ConfigULIDS-ConfigUL OPTIONAL -- Need ON } IDS-PS-ConfigDL ::= CHOICE{ releaseNULL, setup SEQUENCE { semiPersistSchedIntervalDL ENUMERATED { sf10,sf20, sf32, sf40, sf64, sf80, sf128, sf160, sf320, sf640, spare6,spare5, spare4, spare3, spare2, spare1}, numberOfConfSPS-ProcessesINTEGER (1..8), dataMCS ENUMERATED {n0, n1, n2... n31} sessionUEIDINTEGER ( ) implicitReleaseAfter ENUMERATED {e0, e2, e3, e4, e8, spare1,spare2, spare3}, n1PUCCH-AN-PersistentList N1PUCCH-AN-PersistentList,..., [[ twoAntennaPortActivated-r10 CHOICE { release NULL, setupSEQUENCE { n1PUCCH-AN-PersistentListP1-r10 N1PUCCH-AN-PersistentList } }OPTIONAL -- Need ON ]] } } IDS-PS-ConfigUL ::= CHOICE { release NULL,setup SEQUENCE { semiPersistSchedIntervalUL ENUMERATED { sf10, sf20,sf32, sf40, sf64, sf80, sf128, sf160, sf320, sf640, spare6, spare5,spare4, spare3, spare2, spare1}, implicitReleaseAfter ENUMERATED {e2,e3, e4, e8}, dataMCS ENUMERATED {n0, n1, n2... n31} sessionUEID INTEGER( ) p0-Persistent SEQUENCE { p0-NominalPUSCH-Persistent INTEGER(−126..24), p0-UE-PUSCH-Persistent INTEGER (−8..7) } OPTIONAL, -- NeedOP twoIntervalsConfig ENUMERATED {true} OPTIONAL, -- Cond TDD ... } }N1PUCCH-AN-PersistentList ::= SEQUENCE (SIZE (1..4)) OF INTEGER(0..2047) -- ASN1STOP

IDS-PS-Config field descriptions (additonal to IDS-SPS-Config) DataMCSIndicates the Modulation and Coding Scheme (MCS) applicable for theallocation Value n2 corresponds with the value 2 for parameter I_(MCS)in TS 36.213 [23, Table 7.1.7.1-1], and so on. SessionUEID Indicates theUE sessionID of the transmiting UE on the IDS-PS resources as assignedin the IDS-Config.

In addition, in some cases, a common start time may need to be indicatedto the UEs so that each UE is aware of when the persistent configurationbegins. This is not needed in all cases, as the time for initiation maybe as soon as the first IDS-PS-Config is sent. In other embodiments,frame number field (e.g., startFrameNumber (integer)) may be included toindicate on which frame the allocation will begin.

In some embodiments, the ACK/NACK operation for IDS-PS may be sent tothe eNB as described. In these embodiments, it may be desirable toconfigure the IDS-PS resource for first transmissions only andexplicitly allocate (via the PDCCH/ePDCCH DCI) the retransmissions.

In some other embodiments, IDS-PS assignment may be configured such thatthe ACK/NACK responses are received directly by the transmitting UE overthe IDS-RxCCH or in IDS MAC CEs so that HARQ transmissions andretransmission may be sent in the IDS-PS resources without eNBallocations or ACK/NACK indications by the eNB to the D2D transmissions.

In still further embodiments, the system may operate without HARQ andtransmissions are repeated until a maximum number is reached.

In some embodiments where a transmitting UE may adjust the MCS of theIDS transmission, the transmitting UE may indicate the MCS change or newMCS via the IDS-TxCCH or via an IDS-MAC CE, where the IDS-MAC CE is sentover direct device-to-device resources.

In non-D2D scenarios, a PUSCH transmission is scrambled by a Goldsequence initialized by:c _(init) =n _(RNTI)·2¹⁴ +q·2¹³ +└n _(s)/2┘·2⁹ +N _(ID) ^(cell)where n_(RNTI) is the UE C-RNTI or SPS RNTI, and N_(ID) ^(cell) is thecell ID.

For direct UE-to-UE transmission on PUSCH, the transmission is scrambledby the IDS-RNTI of the UE-to-UE session or the IDS-SPS (or IDS-PS) RNTI,whichever is indicated by the encoding of the PDCCH DCI carrying the ULgrant, and by the cell ID of the controlling eNB.

In the PDSCH, in some embodiments, the UE-to-UE communications use thesame scrambling as indicated for the PUSCH as UL procedures are used forUE-to-UE communication in either the UL or DL resources.

In an alternate embodiment, UE-to-UE transmissions in the PDSCH usescrambling based on LTE PDSCH scrambling, where in LTE PDSCH operation,a transmission is scrambled by a Gold sequence initialized by:c _(init) =n _(RNTI)·2¹⁴ +q·2¹³ +└n _(s)/2┘·2⁹ +N _(ID) ^(cell) forPDSCHwhere n_(RNTI) is the UE C-RNTI or SPS RNTI, and N_(ID) ^(cell) is thecell ID.

For direct UE-to-UE transmission on PDSCH and regardless of whether LTEPDSCH-based or PUSCH-based scrambling is used, the transmission isscrambled by the IDS-RNTI of the UE-to-UE session or the IDS-SPS-RNTI(or IDS-PS-RNTI), whichever is indicated by the encoding of the PDCCHDCI carrying the DL allocation grant, and by the cell ID of thecontrolling eNB.

Depending on the availability of reliable feedback at the eNB, theIDS-PUSCH/PDSCH transmission may be adapted via a modulation and codingscheme (MCS) based on channel conditions and available transmit power atthe UEs. In some embodiments, the determination of MCS is made by theeNB using UE's feedback of CQI. CQI measurements may be made on theIDS-PUCCH, PUCCH or other RS transmissions. CQI feedback may be providedeither via the IDS-PUCCH, if there is only one transmitter in thesession, or via a MAC control element, if there are one or moretransmitters in the session. In the case where reliable feedback is notavailable, the eNB may use the most reliable MCS available as a defaultselection.

In some implementations of the embodiments of a UE receiving the otherUE(s) IDS-PUCCH information, a UE may change its transmission powerlevel for the inter-device session based in part on either the receivedsignal level (i.e., assuming a reciprocal channel) or explicit CQI levelindicated in the IDS-PUCCH.

In some embodiments where a transmitting UE may make the decision toadjust the MCS of the UE-to-UE transmission, the transmitting UE maydirectly indicate the MCS change or new MCS via the IDS-TxCCH or via anIDS-MAC CE.

Returning to FIGS. 5A and 5B, the IDS-RS/SRS transmission may be used bythe other UEs to determine whether they are in-range to communicate and,if they are, to determine receive timing window and channel stateinformation (CSI). In some embodiments, these IDS-RS/SRS transmissionsmay be the same as RS/SRS used for conventional channel sounding betweenthe UE and eNB. If used, the configuration of the (IDS-)SRS/RS assignedto one UE of the attempted UE-to-UE session is given to the other UE. Inthis manner, the UEs may determine if there is sufficient signalstrength received from the other UE. This information is transmitted tothe eNB on the IDS-PUCCH assigned to a UE. In some embodiments, ifsufficient signal strength is received from the other UE, and both UEscommunicate this information to the eNB, then the inter-device sessionmay proceed. During the inter-device session, the IDS-SRS/RS, ifassigned, may be used for, among other things, timing alignment, whichmay include receive window alignment by the receiving UE, timing advanceadjustment by the eNB to adjust transmission timing and CQI estimationby the receiving UE. In some embodiments, the UE may use MAC controlelements to indicate CQI per transmitter. Signaling to the eNB using MACcontrol elements may be particularly useful in cases where multiplepossible transmitters are defined in the session for a given receivingUE. In another embodiment, signal quality and timing information isderived from the reference signals associated with the PUCCH orIDS-PUCCH of the other UE.

An IDS specific PUCCH may be assigned to each UE for communicatinginformation to the eNB regarding the inter-device session channel. Thisassignment may be a new PUCCH allocation in addition to a conventionalPUCCH allocation for UE-to-eNB-feedback, or the assignment may be areplacement of the conventional PUCCH with IDS-PUCCH, or the assignmentmay be a replacement of one or more periodic occurrences of theconventional allocated PUCCH (for example, the IDS-PUCCH replaces thePUCCH every n^(th) occurrence). Similarly, an IDS-CCH may be assignedfor communicating control and feedback information directly between UEsin an IDS.

UE1 may send an IDS-PUCCH message to the eNB indicating CSI of thereceived SRS, or PUCCH RS or other reference signal from the other UE.From this feedback, the eNB determines whether it is feasible to startIDS resource allocations.

Then, eNB sends an activation for the IDS-SPS allocation for IDSresources using a PDCCH DCI configured with the inter-device session(IDS) SPS RNTI (512). IDS resources for direct UE-to-UE transmission areallocated via grants contained in the PDCCH, ePDCCH or other DL controlchannels. A resource allocation configured with the IDS-RNTI is sent ina DL control channel (for example, the PDCCH region of the subframe)using downlink control information (DCI) formats. For example, if asession IDS-RNTI is used, this allocation uses a Format 0 or 4 DCI withone additional field to indicate the transmitter granted use of theresources; the transmitter is identified by the session UE-identifier(UE-ID) provided to the UE by the eNB in the session setup message. Theadditional field is not required, however, for IDS-RNTIs defined for thetransmitter (e.g., unidirectional IDS-RNTI). The other UE(s) configuredto use the IDS-RNTI are implicitly assigned the role of receiver forthis resource allocation. The timing of the UE transmission using theindicated IDS resources is relative to the grant transmission and isderived by the UEs from the timing of the grant and the networkconfiguration.

Using the resources indicated by (510), UE1 transmits a data message toUE2 using the designated IDS-PUSCH/PDSCH resources (514). UE2 can send aHARQ ACK/NACK response regarding the received UE-to-UE transmission(515). For example, a NAK can be sent indicating the transmission wasnot successfully received.

In the above process of transmission, HARQ ACK/NACK feedback along withperiodic sounding is continued until the session is explicitlyterminated is by the eNB or the allocation is implicitly releasedaccording the SPS configuration parameters. It should be noted thatwhile CQI from the UE and allocation indication from the eNB are notnecessary for each transmission, the eNB may provide change or adapt theallocation by sending an IDS configured PDCCH/ePDCCH DCI, or furthersend TPC messages to the transmitting UE. Alternatively, thetransmitting UE may receive this information directly from the receivingUE via the IDS-RxCCH or via IDS MAC CEs.

In the above process, the UE2 sends feedback related to the IDS channeland IDS transmissions. This feedback could include CQI/CSI, ACK/NACK,scheduling request or other uplink control information. In some cases,one or more of these information elements can be sent in the samemessage such as an IDS-PUCCH. In other cases, the IDS-PUCCH resourcesfor feedback may be derived from related parameters of the IDStransmission and/or assignment for the purpose of at least NACK/ACK. Insome of these implementations, UE1 is configured to receive at least theACK/NACK feedback from UE2 over the IDS-RxCCH, while the eNB may alsoreceive some or all of the feedback from UE2 over the IDS-PUCCH. Thefeedback to the eNB and UE1 may be separate messages, or the samemessage received by both. In some cases, the eNB may ignore theinformation it receives on the IDS-RxCCH as UE1 is making decisionsbased on the IDS-RxCCH information it receives. In other embodiments,control and feedback information is exchanged directly between UEs viaIDS MAC control elements (CEs) transmitted over the allocated IDSresources.

In some embodiments in this section, a 1 or 2-bit packet cyclic ID isincluded by the transmitting UE in the IDS-PUSCH/-PDSCH message tocombat ACK/NACK errors or loss of one or more IDS-PUCCH or IDS-RxCCHtransmissions. In some embodiments, this indication is sent concurrentlywith the packet transmission (for example, in a packet header orIDS-TxCCH), while in some other embodiments, the indication may be sentin advance of the next of next transmission (for example, on anIDS-PUCCH transmission). This value is incremented by one with every newpacket transmission, so that a receiving UE may recover quickly in caseof ACK/NACK error or missed IDS-PUCCH or IDS-RxCCH transmissions. Inproper operation, the transmitting UE will increment the ID every timethe transmitting UE receives an ACK and will, therefore, provide thereceiving UE with an indication of a new packet transmission. Thebehavior of the receiving UE with a 1-bit ID is indicated in Table 3.

TABLE 3 UL HARQ Operation for UE-UE IDS-SPS Autonomous Mode with 1-bitcyclic packet ID at Receiving UE HARQ feedback Next packet ID sent bythe seen by the receiving UE receiving UE Receiving UE behaviour NACKIncremented Assume new transmission; clear buffer and start processingnew packet (possible missed IDS PUCCH/IDS RxCCH or ACK/NAK error) ACKIncremented New transmission as expected; clear buffer and startprocessing new packet NACK Not-incremented Retransmission as expectedACK Not-incremented Retransmission assumed. Discard as packettransmission already received correctly.

In a two bit or larger cyclic packet ID field, one or more values may bereserved to convey additional information. For example, one value of a2-bit field may be reserved to indicate that the transmitting UE willnot be transmitting more data during the next resource opportunity. Ifthis indication is received, the receiving UE will monitor further SPSopportunities in the IDS-PUSCH until the value is incremented. Inanother example, one value of the 2-bit field may be reserved toindicate that the transmitting UE is relinquishing its transmitter rolein the next SPS opportunity, allowing the receiving UE to assume thetransmitter role in that next opportunity.

Using the IDS-SPS/IDS-PS allocation, UE1 can transmit the message to UE2using the designated IDS-PUSCH/PDSCH resources (516). For example, if aNACK is received by UE1, the UE1 can retransmit the data. Or, if an ACKis received by UE1, UE1 can send another packet. UE2 sends a HARQACK/NACK response regarding the last received UE-to-UE transmission(517). For example, an ACK can be sent indicating the transmission wassuccessfully received.

Depending on the configuration assigned by the eNB, one or both of theUEs send reference signals (RS) (e.g., a sounding reference signal(SRS)) as indicated by the eNB session setup commands (518). Thetransmissions of SRS/RS can continue until the session is terminated.One or both of the UEs send an IDS-PUCCH/PDSCH message indicating CSI ofthe received SRS/RS from the other UE (520).

FIG. 5B is a message sequence diagram 550 illustrating an example signalflow and traffic for an inter-device session in which feedback signalingis transmitted to a network node (e.g., an evolved Node B (eNB)). Theprocedures illustrated in sequence diagram 550 are the same as thoseillustrated above for FIG. 5A, with the exception that after UE1 sendsdata traffic over PUSCH (514), UE2 sends ACK/NACK (and/or other feedbacksignaling) to the eNB (551). The eNB can send an ACK/NACK indication toUE1 (552). Similarly, after UE1 sends data traffic to UE2 over PUSCH(516), UE2 sends ACK/NACK (and/or other feedback signaling) to the eNB(553). The eNB can send an ACK/NACK indication to UE1 (554).

In addition to the configured replacement of the PUCCH by the IDS-PUCCHdescribed, the eNB may allocate different resources for the IDS-PUCCH,for example, through the cqi-PUCCH-ResourceIndex in the CQI-ReportConfigIE, or allocate different periodicities or subframes to differentiatethe IDS-PUCCH and PUCCH transmission received at the eNB. In some ofthese embodiments, the C-RNTI of the UE is used to scramble the PUCCHUCI format 2/2a/2b/3, or other control signalling formats scrambled byan RNTI, when used. In some embodiments, the IDS-RNTI is used toscramble IDS-PUCCH UCI format 2/2a/2b/3, or other control signallingformats scrambled by an RNTI, when used. Scrambling by IDS-RNTI may beuseful to differentiate the IDS-PUCCH transmissions from the PUCCHtransmission, and this may enable the UE to selectively transmit eitherone in a given PUCCH allocation. Other UEs in the inter-device sessionmay make use of reference signals of the PUCCH and/or IDS-PUCCHtransmissions for CQI and timing information.

The IDS-PUCCH transmission may have the same functionality and format asthe conventional PUCCH, except that its contents (CSI, CQI, ACK, SR,etc.) pertain to the IDS channel and IDS transmissions. The function ofthe IDS PUCCH is to provide feedback on IDS communications. In aspectsof this embodiment, a first UE can be configured to receive feedbackfrom a second UE, in response to an IDS direct transmission from thefirst UE to the second UE. In some cases, the first UE can be configuredto receive at least the ACK/NACK feedback so that the first UE candetermine if further retransmissions of the packet are needed. The eNBis also able to receive feedback, such as information related to channelconditions or channel state information, or scheduling requests, on theIDS-PUCCH. In some embodiments, feedback may be given for thetransmitting UE when there are more than two UEs in the inter-devicesession but there is only one transmitting UE. In another embodiment, aUE may determine the worst CQI of multiple transmitters (by receivingand measuring other UEs signals) and report that to the eNB as the CQIof the inter-device session to reduce CQI signalling. The IDS PUCCH canbe used for other functions including sending IDS HARQ ACK/NACKresponses to UE-to-UE packets to be received by the other UE, makingscheduling requests to the eNB (e.g., so that the requesting UE may beassigned IDS transmission resources), and in some cases providing a ULreference signal for the other UEs to measure for making CQI/timingmeasurements. The IDS-PUCCH message may be configured by LTE PUCCHformat 1/1a/1b or format 3 when CSI is not included, and format 2, LTEPUCCH format 2a or LTE PUCCH format 2b when CSI is included.

For IDS-related ACK/NACK transmission, the UE may use the UE-specificassigned IDS-PUCCH resources for transmission of a message configured asLTE PUCCH format 2a or LTE PUCCH format 2b type transmissions, and incases of extended cyclic prefix, Format 2. The IDS-related ACK/NACKtransmissions may also be sent on IDS-PUCCH configured resources for LTEPUCCH format 1a or LTE PUCCH format 1b type message configurations. Insome embodiments for IDS-PUCCH messages configured as LTE PUCCH format1a or LTE PUCCH format 1b, a resource of the IDS-PUCCH transmission tothe eNB can be derived from a mapping of an index of a control channelelement (CCE) used to send a PDCCH DCI IDS allocation to the designatedtransmitter in an inter-device session.

Format 1a/1b is a scheme in LTE, in which ACK/NACK is sent according toa mapping of downlink resources. The ACK/NACK feedback is sent on thePUCCH (or IDS-PUCCH) based on the mapping of downlink control messageresources (i.e., the ACK/NACK feedback resource is not UE-specific orpre-assigned for a particular UE, but instead is simply determined basedupon the downlink control message transmission). For IDS-SPSallocations, the resources location for IDS-SPS is signaled in the ASNas described in this embodiment, and hence further multiplexing is notrequired.

Format 2a/2b is a scheme in LTE in which the ACK/NACK feedback is senton a PUCCH resource that is assigned to a particular UE. Format 2a/2b istypically used for CQI reporting, but it is possible to include ACK/NACKfeedback with the CQI. Format 2 is used for extended cyclic prefixconfigurations, or reporting without ACK/NACK feedback in UE-assignedresources.

Format 3 is a scheme in LTE for sending a large number of ACK/NACK bits.The ACK/NACK feedback is scrambled by the C-RNTI of the UE providing thefeedback such that the eNB, and other UE if configured to do so, candetermine which UE is providing the feedback.

In some embodiments, the resources assigned to a UE for IDS-PUCCHtransmissions (e.g., LTE Format 2, 2a or 2b) and/or the resourcesallocated for IDS-related ACK/NACK responses without CQI (e.g., LTEFormat 1a or 1b) may be different from the resources assigned fornon-IDS PUCCH transmissions.

In further embodiments, the resources assigned for UE-to-UE feedbackcontaining at least ACK/NACK IDS feedback are different than resourcesused for IDS-PUCCH feedback intended to be received by the eNB. Forexample, the set of resources for UE-to-UE ACK/NACK transmissions in LTEIDS-PUCCH 1a/1b is different than the set of resources assigned forIDS-PUCCH feedback messages to the eNB, which may include IDS-relatedCSI, SR, and in some embodiments IDS ACK/NACK, and other non-IDS-PUCCHmessages.

With regard to ACK/NACK feedback, it should be understood that the abovementioned feedback formats used in conventional PUCCH operation may beapplied to the feedback regarding the IDS transmissions. The ACK/NACKfeedback describes the feedback regarding the IDS transmission, but isprovided by the receiving UE to another UE. With regard to RS/SRSoperations described above, the operation is used by the UEs to measurethe channel and provide feedback to the eNB regarding the channelbetween the UEs. This may be instead of, in addition to, or replaced bythe standard PUCCH SRS or RS transmission if present. In embodimentswhere the IDS-PUCCH may be used for the CQI measurement of the UE-to-UEchannel, the CQI estimate may be approximate as the IDS-PUCCH may betransmitted on the band edges. In this configuration, the IDS-PUCCH CQIestimate may not be a valid estimate of the sub-band CQI.

As described above, following the transmission of a data packet from atransmitting UE to a receiving UE, the receiving UE may send a HARQpositive (ACK) or negative (NACK) acknowledgement to the eNB using theIDS-PUCCH allocated to the receiving UE for this IDS. In someembodiments, if the eNB receives a NACK from any of the receiving UEsregarding the transmission, no signalling to the transmitting UE isrequired, and the transmitting UE will make a non-adaptivere-transmission in the same resource indicated by the initial PDCCH DCIgrant for the previous transmission. In some embodiments, the eNB willsignal a NACK to the transmitting UE in the PHICH although the absenceof the transmission implies a NACK.

If the eNB receives an ACK regarding the UE-to-UE transmission from allof the receiving UEs, the eNB can transmit an ACK via the PHICHaccording to ACK/NACK transmission procedures for synchronous HARQ onthe uplink. In addition, if IDS-PUSCH/PDSCH allocation is received bythe transmitting UE in a PDCCH DCI that is configured by the IDS-RNTI,the new data indicator (NDI) in the PDCCH DCI will indicate whether theIDS-PUSCH/PDSCH allocation is for a retransmission or transmission of anew packet.

UL HARQ Operation HARQ feedback PDCCH DCI seen by the UE seen by the UEUE behaviour ACK or NACK NDI = 1 New transmission according to PDCCH DCIACK or NACK NDI = 0 Retransmission according to PDCCH DCI (adaptiveretransmission) ACK None No transmission, keep data in HARQ buffer and aPDDCH UL grant is required to initiate transmissions of new data NACKNone Non-adaptive retransmission

In cases where multiple inter-device sessions are assigned the ULresources for transmission, the eNB may use appropriate scheduling rulesto ensure the ACK/NACK responses in the PHICH will be separable. Forexample, the eNB may ensure that cyclic a shift for the demodulationreference signal (DMRS) field (according to Table 9.1.2-2, of 3GPP TS36.213 v.10.3.0) in the PDCCH DCI uplink grant for each IDS-PUSCHtransport block are different or, at least, are selected such that theydo not map to the same resources and orthogonal code sequence index.

In some embodiments, including the ACK/NACK response implicitly via theNDI in a new PDCCH/ePDCCH DCI UL grant is a more efficient mechanism ofdelivering ACK/NACK information to the transmitting UE; therefore, thesession may be configured such that a UE waits until receiving anotherPDCCH/ePDCCH DCI allocation with NDI in order to determine where anACK/NACK response was received. In further embodiments, the transmittingUE takes no actions until another PDCCH/ePDCCH DCI with NDI is received.

The ACK/NACK feedback from each of the receiving UEs to the eNB iscarried on the respective IDS-PUCCH or the PUSCH/PDSCH region accordingto procedures for a HARQ-ACK of a downlink transmission as given by of3GPP TS 36.213 v.10.3.0. The multiplexing of ACK/NACK for DLtransmissions can be largely reused, for example:

-   -   PUCCH UCI Format 1a/1b. In LTE, of 3GPP TS 36.213 v.10.3.0 the        ACK/NACK resource locations are linked to the location of the        lowest CCE of the PDCCH allocation used for the DL transmission        resource allocation. For IDS-SPS allocations, the resource        location for IDS-SPS is signalled in the ASN. In embodiments        described, the PDCCH/ePDCCH UL grant location may be linked        resources used for ACK/NAK transmission to the eNB in a similar        manner, while it is noted that the UL grant is sent n subframes        prior to the D2D transmission. In some embodiments, the        resources for D2D ACK/NACK transmission may be collocated with        resources for DL transmissions, while in other embodiments, the        resources for D2D ACK/NACK transmission may be located in        different time-frequency resources, in addition to those for DL        transmissions. For IDS-SPS allocations, the resources location        for IDS-SPS is signalled in the ASN as described in this        embodiment, and hence further multiplexing is not required.    -   Format 2a/2b/3. In these cases, the PUCCH UCI is distinguished        by scrambling using the C-RNTI in LTE systems. In this        embodiment, the PUCCH may be scrambled by either the C-RNTI of        the UE, or the IDS-RNTI of session depending on the        configuration.

It can be noted that in the case where the eNB or network assignsmultiple D2D sessions on the same resource, each with different RNTI,the ACK/NACK responses in a UE-to-UE session will be separable at theeNB (or receiving UE) by:

-   -   1. In the case of UCI format 1a/b, the location of the lowest        CCE used for transmission of the UL grants for each IDS-RNTI        transmission will be different, hence leading to mapping to        different resources for ACK/NACK transmission.    -   2. In the case of an IDS-SPS assignment, the location of the        ACK/NACK transmission is assigned by the eNB and, therefore, can        be different for each session if Format 1a/1b is used.    -   3. In the case of UCI Format 2a/2b/3, the IDS-RNTI or the        C-RNTI, whichever is used, of each transmission is different so        that the scrambling of each PUCCH transmission will be        different. In addition, for format 2a/2b different resources may        be assigned to different UEs for IDS-PUCCH CQI feedback        according to the cqi-ReportConfig.

It may also be noted that the information for the location of theACK/NACK response which includes UL grant location and IDS-RNTI (ifused) are known at both the UE session receiver and transmitter.Further, PHY ACK/NACK multiplexing design options are also possible butare beyond the scope of this document.

The physical location of the ACK/NACK channel from the eNB to thetransmitting UE is on the PHICH channel for ACK/NACK responses to anuplink transmission, and/or implicitly indicated by the presence ofanother PDCCH/ePDCCH DCI grant with NDI.

In other embodiments, the allocation by the PDCCH for the UL resourcesmay be asynchronous (i.e., a PDCCH UL grant is required for each HARQretransmission). In these embodiments, the HARQ procedure to beused—either synchronous or asynchronous—is signalled to a UE by the eNBin an RRC message, or may be configured in a specification.

In the embodiments described herein, the ACK/NACK is sent to the eNB onthe PUCCH from the receiving UE of the D2D session, and then sent to thetransmitting UE via the PHICH, and/or implicitly through the presence ofa PDCCH/ePDCCH DCI with NDI. The main purpose of sending the ACK/NACKthrough the eNB is to allow the eNB to allocate resources for eachtransmission. This is most useful in the case of dynamic scheduling,where the eNB needs to know whether the packet transmission is complete(and hence the UL synchronous resources may be released), or whether are-transmission or new first HARQ transmission is needed (and hence theeNB may allocate a new or the same set of resources). If the NACK/ACKwas not readable by the eNB, then it may be difficult for the eNB toallocate resources. Further, if the ACK/NACK was sent with theexpectation that both the other UE and eNB would read it, there ispotential for error at one location—which may lead to the eNB allocatingresources that are unused, or a UE transmitting without a validallocation.

In some other embodiments, it can be noted that if IDS-SPS allocation isused for first HARQ transmissions only, it is also useful for theACK/NACK transmissions to go to the eNB so that the eNB knows toschedule resources for retransmissions outside the IDS-SPS resource asneeded.

The process for HARQ transmissions within PUSCH is described above. Insome embodiments, the transmission of data over PUSCH may occur withoutspecific HARQ acknowledgements. In these cases, a packet may betransmitted one or more times according to a pre-determinedconfiguration. The predetermined number of times a packet isre-transmitted may be configured during a session set-up message, or thenumber may be known through another predefined configuration such asstandardization.

The receiver does not transmit positive or negative acknowledges duringor after a packet transmission. If the packet is not receivedsuccessfully after the configured number of transmissions of a packet,the error is handled by higher layers of the system (e.g., ARQ).

This embodiment may be used in any UE-to-UE session described in thisdisclosure. This embodiment may be particularly useful in multicastbroadcast scenarios as there are multiple receivers and managingre-transmission may be difficult and costly in signaling. In addition,this scheme may be useful for cases where the eNB does not controlre-transmissions as in the UE autonomous mode.

In still further embodiments, transmitting ACK/NACK to the eNB is not asuseful in the longer term allocation cases (semi-persistent withretransmissions, or persistent scheduling) as the continuance of theallocation does not depend on the completing of HARQ packettransmissions. In these cases, the same ACK/NACK message from the UE canbe used; however, the ACK/NACK message can be read by the other UE. TheeNB does not need to receive the ACK/NACK responses in these cases.Therefore, as described herein, the ACK/NACK for some IDS-SPS andpersistent assignments may be configured such that the ACK/NACKresponses are received directly by the other UE as described in theembodiments, or in other cases, the system may operate without HARQ, andretransmission continue until a maximum number is reached.

In a particular embodiment shown in FIG. 9, the IDS-PUCCH may be definedwithin the PUSCH region and not at the band edges. FIG. 9 is a graphicaldiagram showing the sub-band allocation of resources for an inter-devicesession physical uplink control channel. This allocation is differentfrom the normal LTE PUCCH location assignments. In this embodiment, theIDS PUCCH is located in the PUSCH region in order to provide RS for theother UE to measure in order to determine sub-band CQI estimates. TheIDS-PUCCH (901 and 902) locations are assigned in pairs, with adifferent location per slot for slot i (901) and slot i+1 (902), as forPUCCH, with the exception that the locations are not at the band edges.

Either UE1 or UE2 or both of them send an IDS-PUCCH message to the eNBindicating CSI of the received SRS, or PUCCH RS or other referencesignal from the other UE. From this feedback, the eNB determines whetherit is feasible to start IDS resource allocations. Then, the eNB sends anallocation for IDS resources using a PDCCH DCI configured with theinter-device session (IDS) RNTI.

The ACK/NACK response can be sent using IDS-PUCCH resources aspreviously described. In some cases, the ACK/NACK response is sent viaUE-specific assigned IDS-PUCCH, for example, in an LTE Format 2a or 2b(or format 2) type message. In other cases, the ACK/NACK response issent via IDS-PUCCH resources, for example, in an LTE Format 1a or 1btype message. In cases where an LTE Format 1a or 1b type message isused, the specific IDS-PUCCH resources used for the transmission isderived from a mapping of the location of a resource used to send the DLcontrol message to IDS-PUCCH resources.

In some embodiments, the resource allocation is “asynchronous HARQ” suchthat the PDCCH DCI allocates resources for a single IDS transmission;after an IDS transmission, UE1 receives an ACK/NACK response from UE2corresponding to the IDS transmission according to the embodimentsdescribed herein. UE1 can interpret the ACK/NACK feedback on its own anddetermine to retransmit if necessary in the next IDS transmission toUE2. The next IDS transmission maybe allocated by another PDCCH DCItransmission, for example.

In some other embodiments, the resource allocation is “synchronous HARQ”such that the PDCCH message allocates resources for one or more periodicresources for an IDS packet transmission and potential retransmissionsup to a maximum number of retransmissions; after an IDS transmission,UE1 receives an ACK/NACK response from UE2 corresponding to the IDStransmission according to the embodiments described herein and possiblya further PDCCH DCI corresponding to the IDS transmission from the eNB.If a PDCCH DCI corresponding to the IDS transmission is received, in afirst embodiment of interpreting a further PDCCH DCI, UE1 can determineif a new packet transmissions or retransmission is scheduled from theNew Data Indicator (NDI). A further embodiment of interpreting a furtherPDCCH DCI ignores the PDCCH DCI NDI information and proceeds accordingto ACK/NACK feedback from UE2. In either embodiment, the UE1 appliesresources assignment or other information to the transmission asappropriate. If a PDCCH DCI corresponding to the IDS transmission is notreceived or the PDCCH DCI NDI is ignored, the UE can interpret theACK/NACK feedback from the UE2 corresponding to the IDS transmission,and determine to retransmit if necessary in the next IDS transmission toUE2 according the synchronous HARQ assignment. If a NACK was received,then UE1 can retransmit the IDS transmission to UE2 according thesynchronous HARQ assignment. If an ACK was received, then UE1 ceasestransmission of this packet. In some embodiments, the eNB may alsoreceive the ACK from UE2 and, therefore, determine that resources forfurther synchronous HARQ transmission of this packet are not needed andcan be assigned otherwise.

The above mentioned process of allocation/transmission of HARQ ACK/NACKfeedback along with periodic sounding may continue until theinter-device session is terminated or the IDS is otherwise reconfiguredby the eNB.

Depending on the configuration assigned by the eNB, one or both of theUEs send reference signals as indicated by the eNB session setupcommands. The reference signal may be specifically assigned for use inan IDS (i.e., an IDS-RS), or the RS may be an RS normally assigned to aUE for UE-eNB communications.

Either UE1 or UE2 or both send an IDS-PUCCH/PDSCH message to the eNBindicating CSI of the received (IDS-)RS from the other UE. In thisexample, the current receiver, UE2, may also send a scheduling request(SR) if UE2 has data that UE2 wishes to send to UE1.

FIG. 6 is a message sequence diagram 600 illustrating an example networkoperation for an inter-device session. In this packet orientedUE-initiated mechanism 600, a first UE 610 a (UE1) initiates adevice-to-device setup to a second UE 610 b (UE2) by sending a bearerresource allocation request to the network (625). The network can choseto ignore or grant this request based on device and networkcapabilities, as well as policies and traffic loading. If allowed,Mobility Management Entity (MME 615) sends a request to eNB 605 toinitiate a device-to-device radio bearer connection between UE1 and UE2(630). eNB 605 can provide IDS-RNTI and other setup information, andinstructs UE1 and UE2 to report CQI received from the other UE'sRS/PUCCH/IDS-PUCCH signals (635). UE1 and UE2 report received channelconditions (e.g., CQI) of the device-to-device channel to eNB 605 (640).If device-to-device channel conditions are sufficient to establish asession, eNB 605 propagates successful “ACK” to the MME (645). The eNB605 allocates PUSCH/PDSCH resources using IDS-RNTI encoded grants inPDCCH so that packet exchange between UE1 and UE2 now occurs over thedevice-to-device connection, bypassing the network infrastructure (650),as described in FIG. 5.

FIG. 7 is a flow chart 700 illustrating an example process ofinter-device session communications that may be performed by a networknode of a mobile communications network. The network node may be anevolved Node B (eNB) of a communications network, such as a long termevolution (LTE) network, or another network node, described above. Thenetwork node can receive an indication (702) that a first UE (UE1) wantsto communicate with a second UE (UE2). This indication can be a receiveddata packet addressed to the second UE, or the indication can be arequest for resources. The indication can also include a request orindication that UE1 wants to communicate with UE2 in an inter-devicesession (704). In certain instances, the network node can determine(706) that an inter-device session may be possible between UE1 and UE2.The network node can make this determination based on known informationabout UE1 and UE2, such as whether the UEs are in the same cell. Thenetwork node can also base this determination on network loads andchannel conditions—information that is known or that can be discoveredthrough feedback received from the UEs (discussed more below). Thenetwork node can also determine, without an explicit request from theUEs, that an inter-device session can occur and can initiate aninter-device session without a request from the UEs. In short, the UE orthe network node can initiate the inter-device session.

In certain instances, the network node can receive a request (e.g., fromUE1) for resources to communicate data from UE1 to UE2 (707). Thenetwork node can use the request for resources to initiate aninter-device session between UE1 and UE2. Such an initiation can beexecuted based on a number of other factors, including those listedabove.

In some embodiments, after the network node has determined that thenetwork will initiate an inter-device session, the network node canconfigure a first radio resource control RRC message for UE1 (708). Thenetwork node can also configure a second IDS-PUCCH message for UE2(710). The message can configure resources for the UEs to transmitand/or receive data in an inter-device session. For example, the messagemay contain information related to the IDS-SPS allocation including aresources assignment and an IDS-SPS-RNTI. In another example, themessage may contain information related to an IDS-PS allocationincluding a resources assignment. The message may also contain theresources and configuration of feedback information directly between theUEs.

With the first RRC message, or in separate RRC messages, the networknode may transmit to UE1 UE1-configuration information for aninter-device session (IDS) between UE1 and UE2 (712). The UE1configuration information can include a radio network identifier.Similarly, configuration information can be sent to UE2 (714). Thisconfiguration information may include configuration information used byUE2 to measure signals from UE1. The network node can transmit to UE1UE1-configuration information for an inter-device session (IDS) betweenUE1 and UE2 (714). The UE1 configuration information can include a radionetwork identifier. Similarly, configuration information can be sent toUE2 and used by UE2 to measure signals from UE1 (716). Put differently,the network node can transmit a setup message to UE1. The set-up messagecan include an IDS-physical uplink control channel (IDS-PUCCH), a radionetwork identifier, such as an IDS-radio network temporary identifier(IDS-RNTI), an IDS-an RxCCH configuration, an IDS-TxCCH configuration,etc. In certain implementations, configuration information can be usedby UE1 to measure signals from UE2 for feedback purposes, such aschannel state indicators, rank indicators, precoding matrix indicators,etc., from physical uplink control channel (PUCCH), reference signal(RS), etc.

The network node can also transmit a control message that is configuredwith the radio network identifier and identifies a radio resource orpreviously configured resources assignment for the IDS, such that UE1 ispermitted to transmit data directly to UE2 via the radio resource (718).For example, in the case of IDS-SPS assignment, the network node maytransmit an activation of the IDS-SPS resources that were configured byRRC message(s), the activation by PDCCH DCI configured with theIDS-SPS-RNTI or IDS-RNTI of the session as described in the embodiments.

FIG. 10 is a process flow diagram 1000 for transmitting IDS-SPS/IDS-PSresource allocation. A radio resource control (RRC) message can beconfigured with an IDS-RNTI and an IDS-SPS/IDS-PS resource allocationscheme (1002). The RRC message can be transmitted to UE1 in a unicastmessage or to multiple UEs in a multicast (1004). In the case oftransmitting the RRC message to UE1 in a unicast message, the RRCmessage can be transmitted to other UEs of the IDS in separate unicastmessages (1006). At a later time, the resource allocation grant can betransmitted to the UE(s) using a Downlink Control Information (DCI) inthe PDCCH (1008). The DCI is for IDS-SPS activation. In the case ofIDS-PS allocation, further activation messages are not needed at thestart time may be derived or indicated in the RRC message(s).

In certain implementations, UE1 configuration information (as describedin the example of FIG. 7, for example) can be transmitted in a radioresource control (RRC) message. The control message can be transmittedvia a downlink shared channel, such as a physical downlink sharedchannel (PDSCH).

The network node may transmit, to UE2, UE2 configuration information forthe IDS between UE1 and UE2. UE2 configuration information may includethe same radio network identifier as UE1. In some implementations, theradio network identifier is an inter-device session radio networktemporary identifier (IDS-RNTI).

In some implementations, the UE1 configuration information furtherincludes a session UE1-identifier (UE1-ID), and the UE2 configurationinformation further includes a session UE2-identifier (UE2-ID), theUE1-ID being different from the UE2-ID. The control message thatincludes an allocation of the radio resource for the IDS furtherincludes the radio network identifier and an indication of either theUE1-ID or the UE2-ID. Transmitting the control message may also includeor involve transmitting the control message to UE1 and UE2. The controlmessage indicates that UE1 is to transmit and UE2 is to receive if thecontrol message indicates the UE1-ID, and the control message indicatesthat UE2 is to transmit and UE1 is to receive if the control messageindicates the UE2-ID.

For the same radio network identifier, the UE1 configuration informationindicates that UE1 is a transmitter, and the UE2 configurationinformation indicates that UE2 is a receiver. The UE1 configurationinformation can be a first UE1 configuration information, and the UE2configuration information can be a first UE2 configuration information.The radio network identifier included in the first UE1 configurationinformation and the first UE2 configuration information can be a firstradio network identifier. In certain instances, the network node cantransmit a second UE1 configuration information to UE1. The network nodecan also transmit a second UE2 configuration information to UE2. Thesecond UE1 configuration information and the second UE2 configurationinformation include a second radio network identifier. The second radionetwork identifier is different from the first radio network identifierand indicates that, for the second radio network identifier, UE1 is areceiver and UE2 is a transmitter.

In certain aspects of the implementations, the radio network identifierincluded in the UE1 configuration information is a first radio networkidentifier, and the UE2 configuration information includes a secondradio network identifier. The first radio network identifier may be afirst IDS radio network temporary identifier (IDS-RNTI-UE1), and thesecond radio network identifier maybe a second IDS radio networktemporary identifier (IDS-RNTI-UE2).

In certain implementations, the network node may transmit, to UE1, atransmit power control radio network identifier for power controlcommands associated with the IDS. The transmit power control radionetwork identifier can be included in UE1 configuration information. Thenetwork node may transmit at least one power control command configuredwith the transmit power control radio network identifier, the powercontrol command controlling the transmit power for transmissions betweenUE1 and UE2. The power control command can be configured to adjusttransmit power of a reference signal transmitted by UE1 and received byUE2 for channel state information measurement. The transmit powercontrol radio network identifier maybe a Radio Network TemporaryIdentifier (RNTI).

In some instances, more than two UEs can be involved in the inter-devicesession. For example, the network node can transmit, to a third UE(UE3), UE3 configuration information for the IDS among UE1, UE2, andUE3.

FIG. 8 is a flow chart 800 illustrating an example process ofinter-device session communications that may be performed by a userequipment (UE) operating in a wireless communications network. The UE(UE1) may be a cellular handset, such as a cellular phone or smartphone,or may be a tablet PC, or may be any other user equipment that cancommunicate with other user equipment in a wireless communicationsnetwork, such as a long term evolution (LTE) network. UE1 can transmitan indication that UE1 wants to communicate with a second UE (UE2)(810). This indication can be a data packet addressed to the second UE,or the indication can be a request for resources. The indication canalso include a request or indication that UE1 wants to communicate withUE2 in an inter-device session. In certain instance, the network nodecan determine that an inter-device session can occur between UE1 andUE2.

UE1 can receive from the network node UE1-configuration information foran inter-device session (IDS) between UE1 and UE2 (815). The UE1configuration information can include a radio network identifier. UE1can also receive a radio resource control (RRC) message from the networknode (820). UE1 can also receive a resource allocation fortransmitting/receiving feedback from UE2 (830). Put differently, UE1 canreceive a set-up message or messages from the network node. The set-upmessage can include an IDS-physical uplink control channel (IDS-PUCCH),a radio network identifier, such as an IDS-radio network temporaryidentifier (IDS-RNTI), an IDS-RxCCH configuration, and IDS-TxCCH, etc.In certain implementations, configuration information can be used by UE1to measure signals from UE2, such as physical uplink control channel(PUCCH), reference signal (RS), ACK/NACK feedback, channel stateindicators, rank indicators, precoding matrix indicators, etc. Suchsignals can be used for feedback purposes, and ACK/NACK information canbe used to determine whether or not further HARQ transmission is needed.Similarly, configuration information can be sent to UE2 and used by UE2to measure signals from UE1. UE1 can also receive (e.g., with the RRCmessage) an identification of a radio resource for the IDS, such thatUE1 is permitted to transmit data directly to UE2 via the radio resource(825), in some cases including a radio network identifier (e.g.IDS-RNTI, and/or IDS-SPS-RNTI).

UE1 can also receive an activation instruction from the network node(832) in the case of IDS-SPS allocation. The activation can be sent byPDCCH DCI from the eNB configured with the IDS-RNTI or the session, oralternatively, the IDS-SPS-RNTI of the IDS-SPS configuration asdiscussed in the embodiments. In the case of IDS-PS allocation,activation messages are not needed as the start time may be derived orindicated in the RRC message(s) or configuration. UE1 can send data toUE2 using the allocation information (835) received for the IDS-SPS orIDS-PS allocation. UE1 can receive feedback information or a feedbacksignal from UE2 (840).

In certain implementations, UE1 configuration information can bereceived in a radio resource control (RRC) message. The control messagecan be received via a downlink control channel, such as a physicaldownlink control channel (PDCCH) or enhanced physical downlink controlchannel (ePDCCH). The control message can be received in a DownlinkControl Information (DCI) element of the downlink control channel.

A first reference signal can be configured for UE1. Configurationinformation including the first reference signal configuration can beprovided to UE2, e.g., in a radio resource control (RRC) message. Thefirst reference signal configuration can identify a reference signal(RS) resource. The first reference signal configuration may beassociated with a physical uplink control channel configuration. Thephysical uplink control channel configuration is an IDS-specificphysical control channel configuration for an inter-device sessionbetween UE1 and UE2.

The reference signal configuration identifies a reference signal for UE2to monitor from UE1, and can also identify a reference signal resourcefor the inter-device session. The reference signal can be used by UE2 todetermine a channel state between UE1 and UE2. The reference signal canalso be used by UE2 to determine timing alignment for the inter-devicesession. The network node can receive channel state indicator (CSI) fromUE2. For example, the network node can receive a channel state indicatoron an IDS-specific physical uplink control channel. The channel stateindicator can indicate a channel state between UE1 and UE2. The channelstate indicator can be received from UE2 via an IDS-specific physicaluplink control channel. The channel state indicator can include one ormore of a channel quality indicator (CQI), precoding matrix index (PMI),rank indicator (RI), or precoding type indicator (PTI). The CSI canreport a channel state of a direct radio channel from UE1 to UE2.

UE1 can provide feedback to the network node, from which the networknode can determine whether the IDS has been established. For example,the network node can determine, based on the channel state indicatorreceived from UE1 or UE2, that the IDS has been established.

In certain implementations, transmission timing for the IDS radioresource can be based on a timing alignment for an uplink resource fromUE1 to the network node.

UE1 can receive an indication of the feedback received from UE2. Theindication of the feedback may be sent using IDS resources, where UE1has been configured to derive the location and receive at least ACK/NACKHARQ feedback to IDS transmissions. The indication of the feedback maybe sent using IDS-PUCCH resources. The IDS-PUCCH resources may bedifferent from an uplink transmission resource foracknowledgement/negative acknowledgement (ACK/NACK) feedback for eNB toUE downlink transmissions.

In certain aspects of the implementations, the radio resource for theinter-device session may include one of LTE physical uplink sharedchannel (PUSCH) resources or LTE physical downlink shared channel(PDSCH) resources.

The network node may transmit, to UE2, UE2 configuration information forthe IDS between UE1 and UE2. UE2 configuration information may includethe same radio network identifier as UE1. In some implementations, theradio network identifier is an inter-device session radio networktemporary identifier (IDS-RNTI).

In some implementations, the UE1 configuration information furtherincludes a session UE1-identifier (UE1-ID), and the UE2 configurationinformation further includes a session UE2-identifier (UE2-ID), theUE1-ID being different from the UE2-ID. The control message thatincludes an allocation of the radio resource for the IDS furtherincludes the radio network identifier and an indication of either theUE1-ID or the UE2-ID. Transmitting the control message may also includeor involve transmitting the control message to the UE1 and UE2. Thecontrol message indicates that UE1 is to transmit and UE2 is to receiveif the control message indicates the UE1-ID, and the control messageindicates that UE2 is to transmit and UE1 is to receive if the controlmessage indicates the UE2-ID.

In implementations where a single radio network identifier is used, theUE1 configuration information can indicate that the UE1 is atransmitter, and the UE2 configuration information indicates that UE2 isa receiver. The UE1 configuration information can be a first UE1configuration information, and the UE2 configuration information can bea first UE2 configuration information. The radio network identifierincluded in the first UE1 configuration information and the first UE2configuration information can be a first radio network identifier. Incertain instances, the network node can transmit a second UE1configuration information to UE1. The network node can also transmit asecond UE2 configuration information to UE2. The second UE1configuration information and the second UE2 configuration informationinclude a second radio network identifier, the second radio networkidentifier different from the first radio network identifier andindicates that, for the second radio network identifier, UE1 is areceiver and UE2 is a transmitter.

While several implementations have been provided in the presentdisclosure, it should be understood that the disclosed systems andmethods may be embodied in many other specific forms without departingfrom the scope of the present disclosure. The present examples are to beconsidered as illustrative and not restrictive, and the intention is notto be limited to the details given herein. For example, the variouselements or components may be combined or integrated in another systemor certain features may be omitted, or not implemented.

Also, techniques, systems, subsystems and methods described andillustrated in the various implementations as discrete or separate maybe combined or integrated with other systems, modules, techniques, ormethods without departing from the scope of the present disclosure.Other items shown or discussed as coupled or directly coupled orcommunicating with each other may be indirectly coupled or communicatingthrough some interface, device, or intermediate component, whetherelectrically, mechanically, or otherwise. Other examples of changes,substitutions, and alterations are ascertainable by one skilled in theart and could be made without departing from the spirit and scopedisclosed herein.

While the above detailed description has shown, described, and pointedout the fundamental novel features of the disclosure as applied tovarious implementations, it will be understood that various omissionsand substitutions and changes in the form and details of the systemillustrated may be made by those skilled in the art, without departingfrom the intent of the disclosure. In addition, the order of methodsteps not implied by the order they appear in the claims.

What is claimed is:
 1. A method performed by a network node of awireless communications network, the method comprising: receiving, froma first user equipment (UE), signaling of capabilities that indicatewhether the first UE is able to receive inter-device session (IDS) datafrom a second UE and downlink data from the network node in onesubframe; transmitting, to the first UE, configuration information forthe first UE (UE1 configuration information) for an IDS between thefirst UE and the second UE, the UE1 configuration information includinga first IDS radio network temporary identifier (IDS-RNTI); transmittinga radio resource control (RRC) message indicating a resource allocationfor the first UE to communicate directly with the second UE, theindication of resource allocation including a semi-persistent scheduling(SPS) resource allocation; transmitting a downlink control information(DCI) message to the first UE based on the first IDS-RNTI, wherein anIDS-SPS-RNTI is indicated to the first UE in the RRC message and the DCIthat activates the resource allocation is based on an IDS-SPS-RNTI, andthe IDS-SPS-RNTI is the same as the IDS-RNTI; and activating theresource allocation using the DCI.
 2. The method of claim 1, wherein afirst UE session ID is indicated in the UE1 configuration information,and the first UE is indicated as the transmitting UE by including thefirst UE session ID within the DCI.
 3. The method of claim 1, whereinthe transmitting UE for the resource allocation is indicated in the RRCmessage.
 4. The method of claim 1, wherein the DCI is transmitted to thefirst UE using a physical downlink control channel (PDCCH).
 5. Themethod of claim 1, wherein the RRC message comprises a semi-persistentscheduling (SPS) configuration information element.
 6. The method ofclaim 1, further comprising: transmitting, to the second UE,configuration information for the first UE (UE1 configurationinformation) for an inter-device session (IDS) between the first UE anda second UE, the UE1 configuration information including a first IDSradio network temporary identifier (IDS-RNTI); transmitting a downlinkcontrol information (DCI) message to the second UE based on a secondIDS-RNTI; and activating the resource allocation using the DCI.
 7. Themethod of claim 6 wherein the second IDS-RNTI is the same as the firstIDS-RNTI.
 8. The method of claim 6 wherein the second IDS-RNTI is thesame as the IDS-SPS-RNTI.
 9. The method of claim 6, further comprisingindicating that the transmitter on the resources is the first UE byindication in one of the DCI or the RRC message.
 10. The method of claim9, further comprising transmitting UE1 configuration information to thesecond UE.
 11. The method of claim 9, further comprising transmittingthe RRC message to the first UE and the second UE.
 12. The method ofclaim 9, further comprising: transmitting the RRC message to the firstUE and the second UE in a single transmission; and instructing the firstUE and the second UE to transmit a negative acknowledgment (NACK) only;and retransmitting the RRC message upon receiving a NACK.
 13. A methodperformed by a network node of a wireless communications network, themethod comprising: receiving, from a first user equipment (UE),signaling of capabilities that indicate whether the first UE is able toreceive inter-device session (IDS) data from a second UE and downlinkdata from the network node in one subframe; transmitting, to the firstUE, configuration information for the first UE (UE1 configurationinformation) for an IDS between the first UE and the second UE, the UE1configuration information including a first IDS radio network temporaryidentifier (IDS-RNTI); transmitting a radio resource control (RRC)message indicating a resource allocation for the first UE to communicatedirectly with the second UE, the indication of resource allocationcomprises an inter-device session persistent scheduling (IDS-PS) ofresource allocation; transmitting a downlink control information (DCI)message to the first UE based on the first IDS-RNTI, wherein anIDS-SPS-RNTI is indicated to the first UE in the RRC message and the DCIthat activates the resource allocation is based on an IDS-SPS-RNTI, andthe IDS-SPS-RNTI is the same as the IDS-RNTI; and activating theresource allocation using the DCI.
 14. The method of claim 13, whereinthe transmitting UE for the resource allocation is indicated in the RRCmessage.
 15. The method of claim 13, further comprising transmitting tothe first UE a time-to-start in the RRC message.
 16. The method of claim13, further comprising indicating that the first UE is the transmitteron the resources by indication in the RRC message.
 17. The method ofclaim 16, wherein the indication is the first or second IDS-RNTIindicating, respectively, that the first or second UE is thetransmitting UE for the IDS.
 18. The method of claim 16, wherein theindication is the first or second UE session identifier indicating,respectively, that the first or second UE is the transmitting UE for theIDS.